EU CRA szerinti biztonsági támogatási időszakok ISO 27001 alapján

Kedd reggel 08:20-kor egy összekapcsolt B2B átjáró terméktulajdonosa üzenetet kap egy szabályozott ügyféltől: „Kérjük, erősítse meg a 4.6-os firmware-verzió biztonsági támogatási időszakát, a sérülékenységreagálási SLA-t, valamint azt, hogy az eszköz az ötéves szolgáltatási szerződésünk alatt továbbra is jogosult marad-e biztonsági frissítésekre.”

09:00-ra a beszerzés továbbít egy DORA átvilágítási kérdőívet. 10:15-kor a jogi terület azt kérdezi, hogy a hirdetett támogatási időszak összhangban van-e az ügyfélszerződésekkel. 11:00-kor a CISO bekerül egy NIS2 beszállítói kockázati felülvizsgálatba, mert a terméket egy EU-ban működő menedzselt szolgáltató használja. Ebéd után az adatvédelmi terület azt kérdezi, hogy a termékben lévő, már nem támogatott API-könyvtár érintheti-e a személyes adatok GDPR szerinti biztonságát.

A kényelmetlen igazság gyorsan láthatóvá válik. A vállalatnak van ütemterve, javításkezelési folyamata, kiadási naptára és ügyféltámogatási portálja, de nincs irányított bizonyítékkészlete a biztonsági támogatási időszakokra.

Ez a hiányosság lényeges. Az EU kiberreziliencia-rendelete szerint a biztonsági támogatási időszak nem pusztán termékcímke. Olyan életciklus-vállalás, amely hatással van a sérülékenységkezelésre, a frissítések rendelkezésre állására, a beszállítói függőségek kezelésére, az ügyfélkommunikációra, a szerződéses kijelentésekre és a forgalomba hozatalt követő felügyeletre. SaaS-beszállítók, eszközgyártók, szoftverkiadók, felhőszolgáltatók és IKT-szolgáltatók esetében a támogatási időszak olyan megfelelési tárggyá válik, amelyet az auditorok és a szabályozott vevők tesztelni fognak.

A gyakorlati válasz nem egy újabb, leválasztott megfelelési táblázat. A válasz az, hogy a biztonsági támogatási időszakot az ISO/IEC 27001:2022 szerinti információbiztonsági irányítási rendszerben kell irányítani, majd ugyanazokat a bizonyítékokat hozzá kell rendelni a NIS2, DORA, GDPR, NIST CSF 2.0 és COBIT-jellegű auditelvárásokhoz.

Ez a Clarysec működési modellje: az IBIR legyen a bizonyítékképzés motorja, a végrehajtható szabályzatok határozzák meg a felelősségeket, a Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint építse fel a visszakövethetőséget, a Zenith Controls: The Cross-Compliance Guide Zenith Controls pedig szolgáljon több megfelelési keretrendszert lefedő iránytűként.

Miért vált a biztonsági támogatási időszak audittárggyá?

A biztonsági támogatási időszak egy egyszerű kérdésre ad választ: meddig biztosít a gyártó biztonsági frissítéseket, sérülékenységjavítást, kockázatcsökkentési útmutatást és kapcsolódó ügyféltámogatást egy termékhez vagy termékverzióhoz?

A gyakorlatban ez a válasz számos mozgó elemtől függ:

• Termékarchitektúra és karbantarthatóság
• Harmadik féltől származó komponensek és nyílt forráskódú függőségek támogatottsága
• Beszállítói és felhőszolgáltatási vállalások
• Sérülékenységi bejelentések fogadására, elsődleges értékelésére, javítására és közzétételére vonatkozó folyamatok
• Kiadásmenedzsment és tesztelési kapacitás
• Ügyfélszerződéses feltételek és szabályozási kötelezettségek
• Incidensreagálási és szolgáltatást igénybe vevői értesítési útvonalak
• Bizonyítékmegőrzés és jóváhagyási feljegyzések

Ha egy gyártó öt év biztonsági támogatást ígér, de egy kritikus kriptográfiai könyvtár három év után már nem támogatott, a támogatási időszak kockázati döntéssé válik. Ha az ügyfél DORA hatálya alá tartozó pénzügyi szervezet, ugyanez a támogatási időszak az IKT harmadik felekre vonatkozó bizonyosság részévé válik. Ha a termék személyes adatokat kezel, a már nem támogatott szoftver a GDPR szerinti adatkezelés biztonságáért fennálló elszámoltathatóság részévé válhat. Ha a termék NIS2 hatálya alá tartozó alapvető vagy fontos szervezetet támogat, az életciklus-biztonság ellátásilánc-biztonsági kérdéssé válik.

A NIS2 ezt az irányítási nézőpontot kifejezetten megjeleníti. Az 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 részesüljenek képzésben. Az Article 21 megfelelő és arányos technikai, operatív és szervezeti intézkedéseket ír elő, beleértve a kockázatelemzést, az incidenskezelést, az üzletmenet-folytonosságot, az ellátási lánc biztonságát, a biztonságos beszerzést, a biztonságos fejlesztést és karbantartást, a sérülékenységkezelést és közzétételt, az eredményesség értékelését, a kiberhigiéniát, a kriptográfiát, a hozzáférés-szabályozást, az eszközkezelést és a hitelesítést. Az Article 23 a jelentős incidensekre vonatkozó, több szakaszból álló jelentéstételi kötelezettségeket ad hozzá.

A DORA hasonló nyomást teremt a pénzügyi szervezetek számára. IKT-kockázatkezelést, digitális működési reziliencia tesztelését, incidenskezelést és IKT harmadik fél kockázatkezelést ír elő. A DORA Article 28 az IKT harmadik fél kockázatkezelési alapelveit szabályozza, az Article 30 pedig írásbeli szerződéses megállapodásokat követel meg egyértelmű szolgáltatásleírásokkal, biztonsági intézkedésekkel, incidensekhez kapcsolódó segítségnyújtással, auditálási jogokkal, megszüntetési jogokkal és kilépési megállapodásokkal.

A GDPR ehhez hozzáadja az adatvédelmi réteget. Ha a termék személyes adatokat kezel, az adatkezelőknek és adatfeldolgozóknak megfelelő technikai és szervezési intézkedésekre van szükségük az Article 32 alapján, szerződéses egyértelműségre az Article 28 alapján, valamint adatsértési értékelésre és bejelentési felkészültségre az Article 33 és Article 34 alapján.

Ezért a CRA szerinti biztonsági támogatási időszakot IBIR-kontrollcsaládként kell irányítani, nem pedig elkülönített termékmenedzsment-mezőként kezelni.

Az ISO 27001 mint a CRA szerinti biztonsági támogatási időszakok kontrollgerince

Az ISO/IEC 27001:2022 azért értékes, mert skálázható, kockázatalapú és irányítási rendszerre épül. Megköveteli, hogy a szervezet meghatározza a kontextust, az érdekelt feleket, a hatályt és az egymással kölcsönhatásban álló folyamatokat, majd a jogi, szabályozási és szerződéses követelményeket kockázatértékeléssé, kockázatkezeléssé, operatív kontrollokká és bizonyítékokká alakítsa ISO/IEC 27001:2022.

A biztonsági támogatási időszak irányítása szempontjából ez azt jelenti, hogy a szervezetnek:

1. Azonosítania kell a hatály alá tartozó termékeket, verziókat, modulokat, felhőszolgáltatásokat és függőségeket.
2. Azonosítania kell az érdekelt feleket, beleértve az ügyfeleket, szabályozó hatóságokat, forgalmazókat, importőröket, rendszerintegrátorokat, adatfeldolgozókat, al-adatfeldolgozókat, incidensreagálási partnereket és beszállítókat.
3. Rögzítenie kell a jogi, szabályozási és szerződéses támogatási kötelezettségeket.
4. Értékelnie kell azokat a kockázatokat, amelyek megakadályozhatják a támogatási vállalások teljesítését.
5. Ki kell választania a sérülékenységkezelésre, biztonságos fejlesztésre, beszállítói bizonyosságra, incidenskezelésre, üzletmenet-folytonosságra, adatvédelemre és dokumentált információra vonatkozó kontrollokat.
6. Olyan alkalmazhatósági nyilatkozat megjegyzéseket kell készítenie, amelyek megindokolják, miért alkalmazandók a kontrollok.
7. Felül kell vizsgálnia a támogatási időszakot, ha az architektúra, a beszállítói függőségek, a fenyegetettségi kitettség vagy az ügyfélvállalások változnak.

A Zenith Controls három, a témához kapcsolódó ISO/IEC 27002:2022 kontrollt jelöl meg e kormányzási probléma központi horgonypontjaként: 5.31 Jogi, törvényi, szabályozási és szerződéses követelmények, 8.8 Technikai sérülékenységek kezelése és 8.25 Biztonságos fejlesztési életciklus. Nem ezek az egyetlen érintett kontrollok, de ezek adják az irányítás gerincét.

A kulcs a visszakövethetőség. Egy terméktámogatási időszaknak visszakövethetőnek kell lennie a kötelezettségtől a kockázati forgatókönyvig, a kockázati forgatókönyvtől a kiválasztott kontrollokig, a kontrolloktól a szabályzati követelményekig, a szabályzati követelményektől pedig a bizonyítékokig.

A Zenith Blueprint, Kockázatkezelési fázis, 13. lépés közvetlenül leírja ezt a visszakövethetőségi fegyelmet:

„Szabályozások kereszthivatkozása: ha bizonyos kontrollokat kifejezetten a GDPR, NIS2 vagy DORA megfelelés érdekében vezettek be, ezt rögzítheti a kockázati nyilvántartásban (a kockázati hatás indoklásának részeként) vagy az SoA-megjegyzésekben.”

Forrás: Zenith Blueprint: An Auditor’s 30-Step Roadmap, Kockázatkezelési fázis, 13. lépés: kockázatkezelési tervezés és alkalmazhatósági nyilatkozat Zenith Blueprint

Egy CRA szerinti biztonsági támogatási időszak esetében az alkalmazhatósági nyilatkozatban nem elegendő annyit rögzíteni, hogy „a sérülékenységkezelés alkalmazandó”. Meg kell magyarázni, hogy a sérülékenységkezelés azért alkalmazandó, mert a vállalatnak CRA szerinti életciklus-vállalásai, NIS2 szerinti biztonságos fejlesztési és ellátásilánc-elvárásai, DORA szerinti ügyfél-átvilágítási igényei, személyes adatok kezelése esetén GDPR szerinti biztonsági kötelezettségei, valamint szerződéses támogatási ígéretei vannak.

A támogatási ígérettől az irányított életciklusig

A gyártó által meghatározott biztonsági támogatási időszaknak hat irányítási teszten kell átmennie.

Először: meg kell határozni. A szervezetnek szabványos taxonómiára van szüksége, például aktív támogatás, kizárólag biztonsági támogatás, kiterjesztett támogatás, korlátozott támogatás és nem támogatott státusz. Minden státusznak magyaráznia kell a frissítések rendelkezésre állását, a sérülékenységkezelést, az ügyfélkommunikációt és az eszkalációs útvonalakat.

Másodszor: kockázatértékelésnek kell alávetni. Öt év támogatás egy kontrollált frissítési csatornákkal működő, felhőből menedzselt SaaS-terméknél más kockázatot jelent, mint öt év támogatás egy beágyazott eszköznél, ahol terepi korlátok, harmadik féltől származó chipfüggőségek és ügyfél által kezelt telepítési ablakok vannak.

Harmadszor: jóvá kell hagyni. A termék-, biztonsági, jogi, adatvédelmi és ügyféltámogatási területnek, valamint az elszámoltatható vezetésnek jóvá kell hagynia az alapértelmezett időszakot és a kivételeket.

Negyedszer: kommunikálni kell. Az ügyfeleknek érteniük kell a támogatás kezdő dátumát, záró dátumát, a frissítési módszert, a sérülékenység-bejelentési csatornát, a javítási elvárásokat, a támogatás megszűnésének következményeit és az elérhető hosszabbítási lehetőségeket.

Ötödször: nyomon kell követni. A függőségek változnak. A beszállítók megszüntetik a könyvtárak támogatását. Sérülékenységek jelennek meg. Az ügyfélkörnyezetek módosulnak. A támogatási időszak irányításának tartalmaznia kell a komponensek életciklusának nyomon követését, a beszállítói felülvizsgálatot, a sérülékenységi hírcsatornákat, a javítási naplókat, a kiadási tesztelést és az incidensekből levont tanulságokat.

Hatodszor: bizonyítékokkal kell alátámasztani. Ha egy auditor, szabályozó hatóság vagy szabályozott ügyfél bizonyítékot kér, a szervezetnek be kell tudnia mutatni a megfelelési nyilvántartást, a terméktámogatási nyilvántartást, a kockázatértékelést, az SoA-megfeleltetést, a sérülékenységi nyilvántartást, a javítási feljegyzéseket, a beszállítói felülvizsgálatokat, a kiadási jóváhagyásokat és az ügyfélértesítéseket.

A Clarysec szabályzatai ezt gyakorlati szintre hozzák. A vállalati Jogi és szabályozói megfelelési szabályzat Jogi és szabályozói megfelelési szabályzat előírja:

„Minden jogi és szabályozási kötelezettséget hozzá kell rendelni az információbiztonsági irányítási rendszeren (ISMS) belüli konkrét szabályzatokhoz, kontrollokhoz és felelősökhöz.”

Forrás: Jogi és szabályozói megfelelési szabályzat, a szabályzat végrehajtásának követelményei, 6.2.1 pont Jogi és szabályozói megfelelési szabályzat

KKV-k esetében ugyanez a fegyelem egyszerűbb nyilvántartással kezdődik. A KKV Jogi és szabályozói megfelelési szabályzat - KKV Jogi és szabályozói megfelelési szabályzat - KKV kimondja:

„Az ügyvezető köteles egyszerű, strukturált megfelelési nyilvántartást vezetni, amely tartalmazza:”

Forrás: Jogi és szabályozói megfelelési szabályzat - KKV, irányítási követelmények, 5.1.1 pont Jogi és szabályozói megfelelési szabályzat - KKV

A támogatási időszakra vonatkozó vállalást szerepeltetni kell a megfelelési nyilvántartásban, ha azt jogszabály, ügyfélszerződés, ágazati szabályozás vagy szabályozott vevői elvárás vezérli. Nem maradhat kizárólag a kiadási megjegyzésekben vagy a marketinganyagokban.

CRA szerinti biztonsági támogatási időszak nyilvántartása egyetlen műhelymunka keretében

Képzeljünk el egy SaaS-beszállítót, amely összekapcsolt analitikai berendezést értékesít EU-beli logisztikai szolgáltatóknak és pénzügyi szektorbeli ügyfeleknek. A termék tartalmaz egy beágyazott ügynököt, egy felhő API-t, egy mobil adminisztrációs alkalmazást és több nyílt forráskódú könyvtárat. Az értékesítés minden fő berendezésverzióhoz öt év biztonsági támogatást szeretne ígérni.

A CISO célzott műhelymunkát tarthat a termék-, mérnöki, jogi, adatvédelmi és beszállítókezelési területtel.

1. lépés: A támogatási időszakok nyilvántartásának létrehozása

Hozzon létre termékverziónként egy sort, és szerepeltesse benne:

• Termék és verzió
• Kiadási dátum
• Támogatás kezdő dátuma
• Alapértelmezett biztonsági támogatás záró dátuma
• Kiterjesztett támogatási lehetőség
• Frissítések kézbesítési módja
• Sérülékenység-közzétételi csatorna
• Kritikus javítás célideje
• Adatkezelési szerepkör, például adatkezelő, adatfeldolgozó vagy mindkettő
• Kritikus beszállítók és komponensek
• Érintett ügyfélszektorok
• Kockázatgazda
• Jóváhagyás dátuma
• Bizonyítékok helye

Ez a nyilvántartás dokumentált információvá válik az IBIR-ben. A Zenith Blueprint, IBIR-alapozás és vezetés fázis, 6. lépés a dokumentumkezelési elvárást így fogalmazza meg:

„A dokumentumoknak megfelelő azonosítással kell rendelkezniük (cím, esetleg dokumentumszám vagy egyedi azonosító, szerző), megfelelő formátummal, valamint használat előtti megfelelőségi felülvizsgálattal és jóváhagyással.”

Forrás: Zenith Blueprint: An Auditor’s 30-Step Roadmap, IBIR-alapozás és vezetés fázis, 6. lépés: dokumentált információ és az IBIR-dokumentumtár felépítése Zenith Blueprint

A Clarysec vállalati PIMS dokumentált információk és bizonyítékkezelési szabályzata PIMS dokumentált információk és bizonyítékkezelési szabályzata hasonló bizonyítékelveket alkalmaz az adatvédelmi dokumentációra:

„[Minden esetben] Az adatvédelmi vezető / PIMS-vezető KÖTELES dokumentumazonosítót, felelőst, verziószámot, jóváhagyási státuszt, hatálybalépési dátumot és felülvizsgálati dátumot hozzárendelni a REG12-ben, mielőtt PIMS dokumentált információt közzétesz.”

Forrás: PIMS dokumentált információk és bizonyítékkezelési szabályzata, létrehozás, jóváhagyás, verziókezelés és közzététel, 4.2.1 pont PIMS dokumentált információk és bizonyítékkezelési szabályzata

Még akkor is, ha a támogatási időszakok nyilvántartása alapértelmezés szerint nem adatvédelmi dokumentum, ugyanaz a fegyelem alkalmazandó: felelős, verzió, jóváhagyás, hatálybalépési dátum és felülvizsgálati dátum.

2. lépés: A támogatási ígéretek összekapcsolása a kockázatkezeléssel

Minden termékverzióhoz hozzon létre kockázati forgatókönyveket, például:

• Kritikus sérülékenységet fedeznek fel egy támogatott verzióban, de nem áll rendelkezésre mérnöki kapacitás.
• Egy harmadik féltől származó komponens nem támogatottá válik a deklarált biztonsági támogatási időszak vége előtt.
• Egy beszállító megváltoztatja a tárhely helyét vagy alvállalkozóját, és ez érinti a frissítések kézbesítését.
• Egy sérülékenység személyes adatokat érint, és adatvédelmi incidensértékelést vált ki.
• Egy szabályozott pénzügyi ügyfél bizonyítékot kér az IKT harmadik fél rezilienciájáról.

Az ISO/IEC 27001:2022 6.1.1–6.1.3 pontjai biztosítják a tervezési mechanizmust: kockázatok azonosítása, valószínűség és következmények értékelése, kockázatgazdák kijelölése, kezelési módok kiválasztása, a kiválasztott kontrollok összevetése az A melléklettel, az alkalmazhatósági nyilatkozat elkészítése és a maradványkockázat jóváhagyásának megszerzése.

A „nem támogatott komponens a támogatási záró dátum előtt” kockázat esetében a kockázati bejegyzésnek tartalmaznia kell az ISO/IEC 27002:2022 5.31, 8.8 és 8.25 kontrolljait, valamint olyan beszállítói kontrollokat, mint az 5.19 Információbiztonság a beszállítói kapcsolatokban, 5.20 Információbiztonság kezelése a beszállítói megállapodásokban, 5.21 Információbiztonság kezelése az IKT-ellátási láncban és 5.22 Beszállítói szolgáltatások monitorozása, felülvizsgálata és változáskezelése.

3. lépés: Sérülékenységi és javítási bizonyítékszabályok meghatározása

A támogatási időszak csak akkor hiteles, ha a sérülékenységkezelés működik ezen időszak alatt.

A KKV Sérülékenység- és javításkezelési szabályzat - KKV Sérülékenység- és javításkezelési szabályzat - KKV szigorú követelményt állít fel sürgős kitettség esetére:

„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ő rendszereknél.”

Forrás: Sérülékenység- és javításkezelési szabályzat - KKV, a szabályzat végrehajtásának követelményei, 6.1.1 pont Sérülékenység- és javításkezelési szabályzat - KKV

Auditálható feljegyzéseket is megkövetel:

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

Forrás: Sérülékenység- és javításkezelési szabályzat - KKV, irányítási követelmények, 5.4.1 pont Sérülékenység- és javításkezelési szabályzat - KKV

Vállalati környezetekben a vállalati Sérülékenység- és javításkezelési szabályzat Sérülékenység- és javításkezelési szabályzat előírja:

„A biztonsági üzemeltetési csapat köteles központi sérülékenységkezelési nyilvántartást fenntartani, amelyet a CISO vagy delegált hatáskörű személy havonta felülvizsgál.”

Forrás: Sérülékenység- és javításkezelési szabályzat, irányítási követelmények, 5.1 pont Sérülékenység- és javításkezelési szabályzat

A Zenith Blueprint, Kontrollok működésben fázis, 19. lépés az ISO/IEC 27002:2022 8.8 kontroll mögötti operatív elvárást magyarázza:

„Kövesse nyomon az új biztonsági hibákat (például beszállítói riasztások, CVE-hírcsatornák stb. útján) a szoftvereihez és hardvereihez. Értékelje, melyek relevánsak (használjuk ezt a szoftvert? mennyire kritikus a hiba?), és időben alkalmazza a javításokat vagy kockázatcsökkentő intézkedéseket.”

Forrás: Zenith Blueprint: An Auditor’s 30-Step Roadmap, Kontrollok működésben fázis, 19. lépés: technikai kontrollok I Zenith Blueprint

Minden támogatott termékverzióhoz sérülékenységi bizonyítékláncra van szükség: bejelentés fogadása, relevanciaelemzés, súlyosság, érintett verziók, javítási terv, javító kiadás, kockázatcsökkentési útmutató, ügyfélkommunikáció és lezárási jóváhagyás.

4. lépés: A biztonságos fejlesztés összekapcsolása a támogatási időtartammal

A biztonsági támogatás a kiadás előtt kezdődik. Olyan fejlesztési gyakorlatoktól függ, amelyek karbantarthatóvá teszik a terméket.

A KKV Biztonságos fejlesztési szabályzat - KKV Biztonságos fejlesztési szabályzat - KKV kimondja:

„A komponenseket rendszeresen frissíteni kell, amikor biztonsági javítások jelennek meg. Kritikus sérülékenység azonosítása esetén a komponenst haladéktalanul frissíteni vagy cserélni kell.”

Forrás: Biztonságos fejlesztési szabályzat - KKV, a szabályzat végrehajtásának követelményei, 6.6.3 pont Biztonságos fejlesztési szabályzat - KKV

A KKV Alkalmazásbiztonsági követelmények szabályzata - KKV Alkalmazásbiztonsági követelmények szabályzata - KKV előírja, hogy a szerződéseknek és követelményeknek:

„rögzíteniük kell a sérülékenységek közzétételére, a válaszidőkre és a javításkezelésre vonatkozó kötelezettségeket.”

Forrás: Alkalmazásbiztonsági követelmények szabályzata - KKV, irányítási követelmények, 5.3.2 pont Alkalmazásbiztonsági követelmények szabályzata - KKV

Ha a vállalat 2031-ig ígér támogatást, az architektúrának támogatnia kell a karbantartható frissítéseket, a függőségek cseréjét, a biztonságos build-folyamatokat, a regressziós tesztelést és a sürgősségi kiadásokat. Az ISO/IEC 27002:2022 biztonságos fejlesztésre, biztonságos architektúrára, biztonságos kódolásra, biztonsági tesztelésre, kiszervezett fejlesztésre, környezetek szétválasztására és változáskezelésre vonatkozó kontrolljai a támogatási időszak előfeltételeivé válnak.

Egy bizonyítékkészlet CRA, NIS2, DORA és GDPR célokra

Ugyanaz a támogatási időszakra vonatkozó bizonyítékkészlet különböző szabályozási párbeszédekben is felhasználható, de minden keretrendszer másképpen teszi fel a kérdést.

A beszállítói függőség gyakran az a pont, ahol a támogatási vállalások meghiúsulnak. A vállalati Beszállítói függőségi kockázatok kezelésére vonatkozó szabályzat Beszállítói függőségi kockázatok kezelésére vonatkozó szabályzat előírja:

„Beszállítói függőségi nyilvántartás: a VMO köteles naprakész nyilvántartást vezetni valamennyi kritikus beszállítóról, beleértve többek között a nyújtott szolgáltatások/termékek részleteit; azt, hogy a beszállító egyforrásos-e; az elérhető alternatív beszállítókat vagy helyettesíthetőséget; az aktuális szerződéses feltételeket; valamint annak értékelését, milyen hatással járna, ha a beszállító kiesne vagy kompromittálódna.”

Forrás: Beszállítói függőségi kockázatok kezelésére vonatkozó szabályzat, végrehajtási követelmények, 6.1 pont Beszállítói függőségi kockázatok kezelésére vonatkozó szabályzat

A Zenith Blueprint, Kontrollok működésben fázis, 23. lépés figyelmeztet arra, hogy az auditorok a beszállítói megállapodásokat és a beszállítói monitorozás bizonyítékait is vizsgálni fogják:

„Az auditorok mintaszerződéseket vagy szolgáltatási megállapodásokat fognak felülvizsgálni. Kifejezett információbiztonsági záradékokat keresnek, például adatsértési bejelentési határidőket, hozzáférési korlátozásokat, adatkezelési kötelezettségeket, titkosítási követelményeket vagy auditálási jogokat.”

Forrás: Zenith Blueprint: An Auditor’s 30-Step Roadmap, Kontrollok működésben fázis, 23. lépés: szervezeti kontrollok Zenith Blueprint

DORA-ügyfelek esetében ez kritikus. A kritikus vagy fontos funkciókat támogató IKT-szolgáltatások szerződéseiben egyértelmű szolgáltatásleírásokra, alvállalkozási feltételekre, biztonsági intézkedésekre, incidenshez kapcsolódó segítségnyújtásra, audit- és vizsgálati jogokra, megszüntetési jogokra és átállási megállapodásokra van szükség. Az a beszállító, amely nem képes ezeket a vállalásokat támogatni, megakadályozhatja, hogy a gyártó hiteles támogatási időszakot ígérjen.

Kontroll-keresztmegfeleltetés az auditra kész támogatási időszak-irányításhoz

Ez a keresztmegfeleltetés lehetővé teszi, hogy a biztonsági, jogi, termék- és értékesítési csapatok közös nyelvet beszéljenek. A támogatási időszakok nyilvántartása nem csupán CRA-bizonyíték. Beszállítói bizonyosság a NIS2-höz, harmadik felekre vonatkozó bizonyosság a DORA-hoz, az adatkezelés biztonságának támogatása a GDPR-hoz, valamint irányítási artefaktum az ISO 27001 tanúsításhoz.

Az adatvédelmi nézőpont: amikor a támogatás hiánya biztonságtalanná válik

A biztonsági támogatási időszak irányítása nem kizárólag kiberbiztonsági kérdés. Ha a termék személyes adatokat tárol, továbbít vagy kezel, a már nem támogatott szoftver adatvédelmi kockázattá válhat.

A GDPR alkalmazandó az EU-ban letelepedett szervezet tevékenységéhez kapcsolódó adatkezelésre, és az EU-n kívüli szervezetekre is kiterjedhet, ha az EU-ban tartózkodó személyeknek kínálnak árukat vagy szolgáltatásokat, vagy megfigyelik viselkedésüket. A GDPR tágan határozza meg a személyes adat fogalmát, és személyesadat-sértésnek tekinti azt a biztonsági incidenst, amely a kezelt személyes adatok véletlen vagy jogellenes megsemmisítését, elvesztését, megváltoztatását, jogosulatlan közlését vagy az azokhoz való jogosulatlan hozzáférést eredményezi.

A támogatási időszak irányítása szempontjából az adatvédelmi csapatoknak tudniuk kell, mely termékverziók kezelnek PII-t, mely rendszerek támogatottak még, és hogy a sérülékenységek érintik-e a személyes adatok bizalmasságát, sértetlenségét vagy rendelkezésre állását.

A Clarysec vállalati PII biztonsági hozzáférés-szabályozási szabályzata PII biztonsági hozzáférés-szabályozási szabályzata előírja:

„[Mindkét esetben] A rendszer tulajdonosa / alkalmazástulajdonos KÖTELES legalább negyedévente és minden lényeges technikai változást követően rögzíteni a PII-t kezelő rendszerek sérülékenységértékelési lefedettségét a REG12-ben.”

Forrás: PII biztonsági hozzáférés-szabályozási szabályzata, biztonságos konfiguráció és sérülékenységkezelés, 4.7.4 pont PII biztonsági hozzáférés-szabályozási szabályzata

A vállalati Adatfeldolgozók, al-adatfeldolgozók és harmadik felek adatvédelmi kezelésére vonatkozó szabályzat Adatfeldolgozók, al-adatfeldolgozók és harmadik felek adatvédelmi kezelésére vonatkozó szabályzat folyamatos nyomon követést ír elő a magas kockázatú adatvédelmi kapcsolatokhoz:

„[Minden esetben] A beszállítói / beszerzési felelős KÖTELES negyedévente nyomon követni az aktív magas kockázatú adatfeldolgozói és al-adatfeldolgozói kapcsolatokat, valamint évente az egyéb aktív PII-adatfeldolgozói és al-adatfeldolgozói kapcsolatokat a REG08-ban szereplő átvilágítási feltételek, szerződéses státusz, bizonyossági státusz, nyitott ügyek és felülvizsgálati dátumok alapján.”

Forrás: Adatfeldolgozók, al-adatfeldolgozók és harmadik felek adatvédelmi kezelésére vonatkozó szabályzat, folyamatos nyomon követés, segítségnyújtás, adatközlési interfész és kilépés, 4.5.1 pont Adatfeldolgozók, al-adatfeldolgozók és harmadik felek adatvédelmi kezelésére vonatkozó szabályzat

Amikor egy sérülékenység incidenssé válik, a vállalati PII incidens- és adatsértés-kezelési szabályzat PII incidens- és adatsértés-kezelési szabályzat több keretrendszerre kiterjedő kiváltóok-értékelést követel meg:

„[Feltételesen] Az adatvédelmi vezető / PIMS-vezető KÖTELES minden nagy hatású PII-incidens esetében értékelni az alkalmazandó jogi, ágazati, pénzügyi szektorbeli, kiberbiztonsági, szerződéses, ügyfél- és szolgáltatást igénybe vevői jelentéstételi kiváltó eseményeket, és az alkalmazhatósági eredményt rögzíteni a REG01-ben, REG08-ban és REG10-ben.”

Forrás: PII incidens- és adatsértés-kezelési szabályzat, besorolás és adatsértési értékelés, 4.2.6 pont PII incidens- és adatsértés-kezelési szabályzat

Ez a gyakorlati átfedés a CRA szerinti támogatási vállalások, a NIS2 incidenskommunikáció, a DORA szerinti súlyos IKT-incidensek kezelése és a GDPR adatsértési elszámoltathatósága között.

Hogyan tesztelik az auditorok ugyanezt a támogatási időszakra vonatkozó folyamatot?

Egy erős támogatási időszak-irányítási folyamatnak többféle auditmegközelítés mellett is helyt kell állnia. A bizonyítékok nagy része nem változik, de az auditor nézőpontja igen.

A NIST CSF 2.0 kommunikációs rétegként hasznos, mert GOVERN funkciója magában foglalja a jogi, szabályozási, szerződéses és adatvédelmi kötelezettségeket, a kockázatkezelési célokat, a kockázatvállalási hajlandóságot, a szerepköröket, a szabályzatokat és a felügyeletet. Ellátásilánc-eredményei lefedik a beszállítói stratégiát, kritikusságot, szerződéseket, kellő gondosságot, nyomon követést, incidenskoordinációt és a kapcsolat lezárására vonatkozó rendelkezéseket.

A COBIT- és ISACA-jellegű auditorok gyakran az irányítás kialakítására összpontosítanak: ki a döntés felelőse, milyen folyamatot határoztak meg, milyen mutatók jelzik a teljesítményt, hogyan hagyják jóvá a kivételeket, és hogyan kezelik a folyamatos fejlesztést.

A Clarysec vállalati Információbiztonsági szabályzat Információbiztonsági szabályzat rögzíti az ellenőrizhetőség elvét:

„Minden bevezetett kontrollnak auditálhatónak kell lennie, dokumentált eljárásokkal és a működés megőrzött bizonyítékaival alátámasztva.”

Forrás: Információbiztonsági szabályzat, a szabályzat végrehajtásának követelményei, 6.6.1 pont Információbiztonsági szabályzat

Ezt a mondatot minden biztonsági támogatási időszaknak teljesítenie kell.

Támogatás meghosszabbítása, lerövidítése vagy megszüntetése hamis bizonyosság nélkül

A legnehezebb irányítási helyzetek nem a termékbevezetéskor jelentkeznek. Akkor jelennek meg, amikor a valóság megváltozik.

Szükség lehet a támogatás meghosszabbítására, mert szabályozott ügyfelek függnek a terméktől, a migráció nem megvalósítható, vagy egy ágazati ügyfélnek szerződéses folytonossági igénye van. Szükség lehet a támogatás lerövidítésére vagy korlátozására, mert egy beszállító megszünteti a biztonsági karbantartást, egy komponens javíthatatlanná válik, egy platform eléri technikai korlátait, vagy a termékarchitektúra nem képes biztonságosan támogatni egy sérülékenységi osztályt.

Egy kontrollált támogatási időszak-változásnak tartalmaznia kell:

• Változási kiváltó esemény, például beszállítói életciklus vége, kritikus sérülékenység, ügyfélszerződés vagy szabályozási változás
• Érintett termékek, verziók, ügyfelek és szektorok
• Személyes adatokra és kritikus szolgáltatásokra gyakorolt hatáselemzés
• Beszállítói és komponens-megvalósíthatósági felülvizsgálat
• Kockázatértékelés és maradványkockázati döntés
• Frissített támogatási időszak nyilvántartás
• Frissített ügyfélértesítés és szerződéses álláspont
• Frissített SoA-megjegyzések, ha a kontrollok vagy kötelezettségek változnak
• Vezetői jóváhagyás és felülvizsgálati dátum

A vállalati Koordinált sérülékenység-közzétételi szabályzat Koordinált sérülékenység-közzétételi szabályzat hasznos, ha a változást sérülékenység váltja ki:

„Minden megerősített sérülékenységhez javítási vagy kockázatcsökkentési tervet kell kidolgozni. A javítás végrehajtását a súlyosság alapján kell priorizálni. Például a kritikus sérülékenységeket, ahol megvalósítható, 14 napon belül javítani vagy mérsékelni kell, aktív kihasználás észlelése esetén pedig ennél hamarabb; az alacsonyabb súlyosságú problémákat észszerű határidőn belül kell kezelni.”

Forrás: Koordinált sérülékenység-közzétételi szabályzat, végrehajtási követelmények, 6.6 pont Koordinált sérülékenység-közzétételi szabályzat

Ha a teljes javítás nem szállítható azonnal, a kompenzáló kontrollok, a funkció letiltása, a fokozott megfigyelés vagy az ügyfélkonfigurációs útmutató átmenetileg elfogadható lehet, de a döntést dokumentálni és kommunikálni kell.

Gyakorlati Clarysec ellenőrzőlista a támogatási időszakra való felkészültséghez

Használja ezt az ellenőrzőlistát bármely CRA szerinti biztonsági támogatási időszakra vonatkozó vállalás közzététele vagy megújítása előtt.

• Szerepel-e a termék és verzió a támogatási időszakok nyilvántartásában?
• Jóváhagyta-e a támogatás záró dátumát a termékterület, a biztonsági terület és az elszámoltatható vezetés?
• Hozzá vannak-e rendelve a jogi, szabályozási és szerződéses kiváltó tényezők a megfelelési nyilvántartásban?
• Szerepel-e a támogatási időszak kockázati forgatókönyve a kockázati nyilvántartásban?
• Hozzá vannak-e rendelve a kontrollok az alkalmazhatósági nyilatkozatban, beleértve adott esetben az 5.31, 8.8 és 8.25 kontrollokat?
• Hozzá vannak-e rendelve a kritikus beszállítók és komponensek a beszállítói függőségi nyilvántartásban?
• Van-e bizonyíték arra, hogy a komponensek a támogatási időszak alatt javíthatók vagy cserélhetők?
• Meghatározták-e a sérülékenységi bejelentések fogadására, elsődleges értékelésére, javítására és közzétételére vonatkozó felelősségeket?
• Összhangban vannak-e a kritikus javításokra vonatkozó SLA-k a szabályzattal és az ügyfélszerződésekkel?
• Megőrzik-e a javítási naplókat, a kiadási feljegyzéseket és a sérülékenységi döntéseket?
• Lefedik-e sérülékenységértékelési bizonyítékok a személyes adatokat kezelő rendszereket, ahol PII-kezelés történik?
• Összhangban vannak-e az ügyfélértesítések, támogatási nyilatkozatok és szerződéses feltételek?
• Van-e folyamat a támogatás kockázati jóváhagyással történő meghosszabbítására, lerövidítésére vagy megszüntetésére?
• Kapnak-e a vezetőségi felülvizsgálatok támogatási időszakra, beszállítókra, sérülékenységekre és incidensekre vonatkozó bemeneteket?
• Előállíthatók-e a bizonyítékok 48 órán belül ügyfélaudit vagy hatósági megkeresés esetén?

A vállalati PIMS monitorozási, audit- és fejlesztési szabályzat PIMS monitorozási, audit- és fejlesztési szabályzat megerősíti a vezetőségi felülvizsgálati fegyelmet az adatvédelmi programokban:

„[Mindkét esetben] A felső vezetés KÖTELES minden vezetőségi felülvizsgálat során áttekinteni a REG12-ben a PIMS meg nem felelésre, helyesbítő intézkedésre, monitorozási eredményre, audit eredményre, adatvédelmi kockázatra, beszállítói bizonyosságra és érdekelt felek változásaira vonatkozó bemeneteket.”

Forrás: PIMS monitorozási, audit- és fejlesztési szabályzat, PIMS vezetőségi felülvizsgálat, 4.3.5 pont PIMS monitorozási, audit- és fejlesztési szabályzat

A biztonsági támogatási időszak irányításánál ugyanezt a felülvizsgálati ritmust kell alkalmazni az egész IBIR-ben: a sérülékenységeknek, a javítási teljesítménynek, a beszállítói bizonyosságnak, az ügyfélvállalásoknak, az incidenseknek, a támogatási kivételeknek és a helyesbítő intézkedéseknek be kell kerülniük a vezetőségi felülvizsgálatba.

Tegye igazolhatóvá a biztonsági támogatási időszakot

Az EU kiberreziliencia-rendelete megváltoztatja a termékbiztonságról való gondolkodást. Arra készteti a gyártókat és szoftverszolgáltatókat, hogy a kiadás napján túl gondolkodjanak. A biztonsági támogatási időszak olyan életciklus-ígéretté válik, amelyet meg kell tervezni, irányítani, nyomon követni és bizonyítékokkal alátámasztani.

A CISO-k számára a tanulság egyértelmű: ne engedjék, hogy a támogatási időszak kizárólag termékmarketingben szerepeljen. A megfelelési vezetők számára: ne építsenek külön CRA-bizonyítéksilót. Az auditorok számára: teszteljék, hogy a támogatási vállalások visszakövethetők-e kockázatokhoz, kontrollokhoz, beszállítókhoz, incidensekhez és dokumentált jóváhagyásokhoz. Az üzleti felelősök számára: tartsák szem előtt, hogy a hiteles támogatási időszak piaci előnnyé válhat, különösen NIS2 által szabályozott szektorok, DORA hatálya alá tartozó pénzügyi szervezetek és adatvédelemre érzékeny ügyfelek kiszolgálásakor.

A Clarysec a következőkkel támogatja a gyakorlati bevezetést:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint az IBIR-visszakövethetőség, a dokumentált információ, az SoA-megfeleltetés és az auditra való felkészültség kialakításához
• Zenith Controls: The Cross-Compliance Guide Zenith Controls az ISO/IEC 27002:2022 kontrollok NIS2, DORA, GDPR, NIST CSF 2.0 és auditelvárások szerinti megfeleltetéséhez
• Vállalati és KKV szabályzatcsomagok sérülékenységkezeléshez, biztonságos fejlesztéshez, jogi megfeleléshez, beszállítói függőségekhez, adatvédelmi bizonyítékokhoz és incidensreagáláshoz
• Gyakorlati nyilvántartások és bizonyíték-munkafolyamatok, amelyek a támogatási időszakra vonatkozó ígéreteket auditálható irányítássá alakítják

A következő lépés egyszerű: válasszon ki egy kiemelt termékverziót, és építse fel annak biztonsági támogatási időszakra vonatkozó bizonyítékdossziéját. Térképezze fel a kötelezettséget, hagyja jóvá a támogatási időszakot, tesztelje a sérülékenységkezelési folyamatot, ellenőrizze a beszállítói függőségeket, erősítse meg az ügyfélkommunikációt, és őrizze meg a feljegyzéseket.

Ha egyetlen terméket meg tud védeni bizonyítékokkal, a modell skálázható. Ha egyetlen terméket sem tud megvédeni bizonyítékokkal, a hiányosság nem dokumentációs probléma. Irányítási probléma.

Töltse le a Zenith Blueprint anyagot, használja a Zenith Controls útmutatót a bizonyítékok megfeleltetéséhez, vagy kérjen Clarysec felkészültségi értékelést, hogy a CRA szerinti biztonsági támogatási időszakok auditra alkalmas ISO 27001 irányítássá váljanak.