CVD NIS2- és DORA-környezetben: ISO 27001 szerinti bizonyítéktérkép

Kedden 08:17-kor az információbiztonsági postafiók üzenetet kap egy független kutatótól. A tárgymező nyugodt, szinte udvarias: „Lehetséges fiókátvétel az ügyfélportálon.” Az üzenet tartalma már kevésbé megnyugtató. A kutató állítása szerint a SaaS-alkalmazásban lévő láncolt sérülékenység lehetővé teszi, hogy az egyik tenant hozzáférjen egy másik tenant számlanyilvántartásaihoz. A mellékletben egy proof of concept található, a közzétett PGP-kulccsal titkosítva.

Maria, a FinanTechSaaS új CISO-ja számára az időzítés aligha lehetne rosszabb. A vállalat éppen most írt alá jelentős szerződést egy kiemelt uniós bankkal. Az ügyfél átvilágítási csapata már bekérte a „koordinált sérülékenység-közzétételi szabályzatot” és a végrehajtás bizonyítékait, kifejezetten hivatkozva a NIS2 és DORA követelményeire. A vállalatnak van security@ e-mail-címe, de azt egyetlen fejlesztő figyeli. Nincs formális bejelentés-kezelési nyilvántartás, nincs meghatározott validálási SLA, nincs vezetői eszkalációs útvonal, és nincs auditnyom.

Egyszerre három óra indul el.

Az első óra működési jellegű. Valós-e a sérülékenység? Kihasználható-e éles környezetben? Történik-e aktív visszaélés?

A második óra szabályozási jellegű. Ha ügyféladatok kerültek kitettségbe, elindul a GDPR szerinti incidensértékelés. Ha a szolgáltatásnyújtás érint egy NIS2 szerinti alapvető vagy fontos szervezetet, aktiválódhatnak az incidensbejelentési küszöbértékek. Ha a vállalat pénzügyi szervezet vagy pénzügyi szolgáltatásokat támogató IKT-szolgáltató, relevánssá válhatnak a DORA incidenskezelési, osztályozási, eszkalációs és ügyfélkommunikációs szabályai.

A harmadik óra bizonyítékalapú. Hat hónappal később egy ISO/IEC 27001:2022 auditor, pénzügyi szektorbeli felügyelet, ügyfélbizonyossági csapat vagy belső auditbizottság felteheti a kérdést: „Mutassák be, hogyan kezelték ezt a sérülékenységet.”

Sok szervezet ennél a kérdésnél szembesül azzal, hogy a koordinált sérülékenység-közzététel nem pusztán egy biztonsági postafiók. Ez irányítási rendszer. Szükséges hozzá szabályzatgazda, nyilvános bejelentési csatorna, triázs-munkafolyamat, javítási SLA-k, beszállítói eszkaláció, incidensdöntési logika, adatvédelmi felülvizsgálat, vezetői jelentéstétel és igazolható bizonyíték.

A Clarysec a CVD-t integrált kontrollmintaként kezeli, nem önálló bejövő postafiókként. A Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint dokumentumban a sérülékenységek kezelése a Controls in Action fázisban, a 19. lépésnél, a Technological Controls I alatt jelenik meg, ahol az iránymutatás egyértelmű: a szervezeteknek nem passzívan archiválniuk kell a sérülékenységi megállapításokat, hanem triázsolniuk, hozzárendelniük és lezárásig nyomon követniük azokat. Ugyanez az elv érvényes a külső bejelentésekre is. Ha valaki jelzi, hogyan hibásodhat meg a szolgáltatás, a valódi kérdés az lesz: bizonyítani tudják-e, hogy átvették, értékelték, priorizálták, javították, kommunikálták és beépítették a tanulságokat?

Miért lett a CVD NIS2 és DORA szerint igazgatósági szintű kérdés

A biztonságtudatos szervezetek évek óta ösztönzik az etikus hackereket a sérülékenységek bejelentésére, mert ez jó gyakorlat. A NIS2 és a DORA alapján ez a gyakorlat a szabályozott digitális reziliencia részévé vált.

A NIS2 számos közepes méretű és nagyobb szervezetre alkalmazandó a magas kritikalitású és egyéb kritikus ágazatokban, ideértve a digitális infrastruktúra-szolgáltatókat, felhőszolgáltatókat, adatközpont-szolgáltatókat, menedzselt szolgáltatókat, menedzselt biztonsági szolgáltatókat, valamint bizonyos digitális szolgáltatókat, például online piactereket, keresőmotorokat és közösségi hálózati platformokat. Mérettől függetlenül alkalmazandó lehet olyan kategóriákra is, mint a bizalmi szolgáltatók, DNS-szolgáltatók, TLD-nyilvántartók, valamint nyilvános elektronikus hírközlő hálózatok vagy szolgáltatások nyújtói.

A NIS2 Article 21 előírja, hogy az alapvető és fontos szervezetek megfelelő és arányos technikai, operatív és szervezeti kiberbiztonsági kockázatkezelési intézkedéseket vezessenek be, minden veszélyt figyelembe vevő megközelítéssel. A minimális területek egyike a hálózati és információs rendszerek beszerzésének, fejlesztésének és karbantartásának biztonsága, beleértve a sérülékenységek kezelését és közzétételét. Ugyanez az alapkövetelmény kiterjed az incidenskezelésre, az ellátási lánc biztonságára, az üzletmenet-folytonosságra, a hozzáférés-szabályozásra, az eszközkezelésre, a képzésre, a kriptográfiára és a kontrollhatékonyság értékelésére szolgáló eljárásokra is.

A NIS2 Article 20 a vezetői elszámoltathatóságot is kifejezetté teszi. A vezető testületeknek jóvá kell hagyniuk a kiberbiztonsági kockázatkezelési intézkedéseket, felügyelniük kell a végrehajtást, és képzésen kell részt venniük. Egy CVD-program esetében ez azt jelenti, hogy az igazgatóságnak vagy a felső vezetésnek értenie kell a bejelentési csatornát, a sérülékenység-kezelési reagáló csoportot, a validálási határidőket, a javítási elvárásokat, a beszállítói függőségeket és az incidensbejelentési kiváltó feltételeket.

A DORA 2025. január 17-től ágazatspecifikus rendszert hoz létre a pénzügyi szervezetek számára. Lefedi az IKT-kockázatkezelést, az IKT-val kapcsolatos incidensjelentést, a digitális működési reziliencia tesztelését, az információmegosztást, az IKT-val kapcsolatos harmadik fél kockázatokat, a szerződéses követelményeket, a kritikus IKT-szolgáltató harmadik felek felügyeletét és a felügyeleti együttműködést. A DORA hatálya alá tartozó pénzügyi szervezetek esetében a DORA általában elsőbbséget élvez a NIS2-höz képest az IKT-kockázatkezelés és incidensjelentés terén, mivel ágazatspecifikus uniós jogi aktus. A gyakorlati követelmény azonban változatlan: a pénzügyi szervezeteknek és az őket kiszolgáló IKT-szolgáltatóknak strukturált, dokumentált és tesztelhető folyamatot kell működtetniük az IKT-gyengeségek azonosítására, elemzésére, osztályozására, eszkalálására, javítására és a tanulságok levonására.

Egy sérülékenységi bejelentés indulhat technikai megállapításként, válhat biztonsági eseménnyé, eszkalálódhat incidenssé, kiválthat GDPR szerinti személyesadat-sértési értékelést, beszállítói intézkedést igényelhet, majd később megjelenhet az ISO/IEC 27001:2022 alkalmazhatósági nyilatkozatában. Ezért a CVD-t egységes működési modellként kell kialakítani a biztonság, a megfelelés, a mérnöki terület, a jogi funkció, az adatvédelem, a beszerzés és a vezetés között.

Az ISO 27001 alapja: a közzétételtől az ISMS-bizonyítékig

Az ISO/IEC 27001:2022 biztosítja a CISO-k és megfelelési vezetők számára azt az irányítási rendszert, amely a CVD-t auditálhatóvá teszi.

A 4.1–4.4 pontok előírják, hogy a szervezet értse a belső és külső körülményeket, az érdekelt felek követelményeit, az ISMS határait és a más szervezetekkel fennálló függőségeket. Itt kerülnek be az ISMS-be a NIS2, a DORA, a GDPR, az ügyfélszerződések, a beszállítói kötelezettségek és a sérülékenység-közzétételi vállalások.

Az 5.1–5.3 pontok vezetői elszámoltathatóságot teremtenek. A felső vezetésnek összhangba kell hoznia az információbiztonságot a stratégiai iránnyal, erőforrásokat kell biztosítania, felelősségi köröket kell kijelölnie, és gondoskodnia kell arról, hogy az ISMS elérje a tervezett eredményeket. CVD esetében ez a sérülékenység-kezelési reagáló csoport kijelölését, a maradványkockázat elfogadására vonatkozó hatáskör meghatározását és a nagy hatású sérülékenységek vezetői eszkalálását jelenti.

A 6.1.1–6.1.3 pontok adják a kockázatkezelési motort. A szervezetnek meg kell határoznia a kockázati kritériumokat, értékelnie kell az információbiztonsági kockázatokat, ki kell jelölnie a kockázattulajdonosokat, ki kell választania a kockázatkezelési lehetőségeket, össze kell vetnie a kontrollokat az A melléklettel, el kell készítenie az alkalmazhatósági nyilatkozatot, és jóváhagyást kell szereznie a maradványkockázatra. A 8.1–8.3 pontok ezt követően előírják az operatív kontrollt, a tervezett változtatásokat, a külső fél által biztosított folyamatok ellenőrzését, a kockázatértékeléseket tervezett időközönként vagy jelentős változások után, valamint a kockázatkezelési eredmények bizonyítékait.

A Zenith Blueprint Risk Management fázisának 13. lépése az alkalmazhatósági nyilatkozatot többként írja le, mint megfelelési táblázatot:

„A SoA lényegében áthidaló dokumentum: összekapcsolja a kockázatértékelést/kockázatkezelést a ténylegesen meglévő kontrollokkal.”
Forrás: Zenith Blueprint: An Auditor’s 30-Step Roadmap, Risk Management fázis, 13. lépés: Risk Treatment Planning and Statement of Applicability (SoA) Zenith Blueprint

A koordinált sérülékenység-közzététésnél a SoA-nak össze kell kötnie a szabályozási kötelezettségeket, az üzleti kockázatot, az A melléklet szerinti kontrollokat, a szabályzati pontokat és a működési bizonyítékokat.

A cél nem párhuzamos megfelelési silók létrehozása. A CVD-szabályzatnak szabályozott ISMS-folyamatnak kell lennie, amely egyszerre támogatja az ISO/IEC 27001:2022 tanúsítást, a NIS2-megfelelést, a DORA-felkészültséget, az ügyfélbizonyosságot és a biztonsági üzemeltetést.

A szabályzati alap: mit kell kimondania a CVD-szabályzatnak

Az első látható kontroll a nyilvános bejelentési csatorna. A kutatóknak, ügyfeleknek, beszállítóknak és partnereknek tudniuk kell, hová jelentsék a sérülékenységeket, és hogyan védjék az érzékeny bizonyítékokat.

A Clarysec 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 vállalati alapkövetelményt biztosít:

„Nyilvános bejelentési csatornák: A szervezetnek egyértelmű csatornát kell fenntartania a sérülékenységek bejelentésére, például külön biztonsági kapcsolattartási e-mail-címet (például security@company.com) vagy webes űrlapot. Ezt az információt a vállalati weboldal biztonsági oldalán kell közzétenni a szervezet PGP nyilvános kulcsával együtt, hogy lehetővé váljanak a titkosított beküldések.”
Forrás: Koordinált sérülékenység-közzétételi szabályzat, végrehajtási követelmények, 6.1 pont

Ez a pont egy gyakori auditmegállapítást kezel. Sok szervezet állítja, hogy fogad bejelentéseket, de a bejelentési útvonal el van rejtve, nincs titkosítva, vagy nem a megfelelő csapat kezeli. Az érett csatorna nyilvános, biztonságos, felügyelt, és felelős funkcióhoz van rendelve.

A következő kontroll a reagálási fegyelem. Egy kritikus bejelentésre adott csend közzétételi kockázatot, reputációs kockázatot és kihasználási kockázatot teremt. A Koordinált sérülékenység-közzétételi szabályzat konkrét átvételi visszaigazolási és validálási elvárást határoz meg:

„Triázs és tudomásulvétel: A bejelentés átvételekor a VRT köteles azt rögzíteni, és 2 munkanapon belül visszaigazolást küldeni a bejelentőnek, nyomon követési hivatkozás hozzárendelésével. A VRT köteles előzetes súlyossági értékelést végezni, például CVSS-pontozás használatával, és szükség esetén az IT- és fejlesztői csapatok támogatásával 5 munkanapos célidőn belül ellenőrizni a problémát. A kritikus sérülékenységeket, például a távoli kódfuttatást vagy jelentős adatsértést lehetővé tevő sérülékenységeket gyorsítottan kell kezelni.”
Forrás: Koordinált sérülékenység-közzétételi szabályzat, végrehajtási követelmények, 6.4 pont

Ez a megfogalmazás azonnali bizonyítási pontokat hoz létre: átvételi idő, visszaigazolási idő, nyomon követési hivatkozás, előzetes súlyosság, validálási eredmény és gyorsított kezelésről szóló döntés.

KKV-k esetében a Clarysec ugyanezt a logikát alkalmazza arányos végrehajtással. Az Alkalmazásbiztonsági követelmények szabályzata-sme Alkalmazásbiztonsági követelmények szabályzata - SME előírja a szervezetek számára, hogy:

„határozzák meg a sérülékenység-közzétételre, válaszidőkre és javítások telepítésére vonatkozó kötelezettségeket.”
Forrás: Alkalmazásbiztonsági követelmények szabályzata-sme, irányítási követelmények, 5.3.2 pont

Az elszámoltathatósághoz nincs szükség nagy termékbiztonsági csapatra. Egyértelmű kötelezettségekre, reális határidőkre, megnevezett felelősökre és a folyamat működését igazoló bizonyítékokra van szükség.

A CVD bejelentés-kezelési munkafolyamata: a kutatói e-mailtől a döntési bejegyzésig

A jó bejelentés-kezelési munkafolyamat elég egyszerű ahhoz, hogy nyomás alatt is működjön, és elég teljes ahhoz, hogy megfeleljen egy auditornak. Külön csatornával kell indulnia, például security@[company] címmel, webes űrlappal vagy közzétett security.txt fájllal. A beküldési útvonalnak lehetővé kell tennie a titkosított bizonyítékok, az érintett termék vagy végpont, a reprodukciós lépések, a bejelentő elérhetőségi adatai, a preferált közzétételi időzítés, valamint az adatkitettségre vagy aktív kihasználásra utaló jelzések megadását.

A beérkezést követően a sérülékenység-kezelési reagáló csoportnak bejegyzést kell létrehoznia egy GRC-eszközben, jegykezelő platformon, sérülékenységkezelési rendszerben vagy szabályozott nyilvántartásban. Az eszköz kevésbé fontos, mint a következetesség és a bizonyítékok minősége.

A munkafolyamatnak ezt követően hét operatív lépésen kell végigmennie.

1. Bejelentésfogadás: a bejelentés a nyilvános csatornán keresztül érkezik be, és automatikusan vagy manuálisan naplózásra kerül.
2. Átvételi visszaigazolás: a VRT 2 munkanapon belül válaszol, és nyomon követési hivatkozást rendel hozzá.
3. Validálás: a műszaki csapat reprodukálja a problémát, megerősíti az érintett rendszereket, és előzetes súlyossági pontozást végez.
4. Eseményértékelés: a VRT meghatározza, hogy a sérülékenység csupán gyengeség, információbiztonsági esemény vagy incidens.
5. Eszkaláció: a magas vagy kritikus problémákat szükség szerint továbbítani kell a rendszergazdáknak, a CISO-nak, az adatvédelmi és jogi funkciónak, a beszállítóknak és a vezetésnek.
6. Javító intézkedés: a felelős csapat javítást, kockázatcsökkentő intézkedést, kompenzáló kontrollt vagy átmeneti korlátozást alkalmaz.
7. Lezárás: a VRT ellenőrzi a javítást, kommunikál a bejelentővel, frissíti a bizonyítékfájlt, és rögzíti a tanulságokat.

A Clarysec ezt az operatív lépést az ISO/IEC 27002:2022 A.5.25, Információbiztonsági események értékelése és az azokról való döntés kontrollhoz, valamint az A.8.8, Technikai sérülékenységek kezelése kontrollhoz rendeli a Zenith Controls: The Cross-Compliance Guide Zenith Controls alapján. Az A.5.25 esetében a Zenith Controls kifejti, hogy az eseményértékelés a nyers megfigyelési riasztások és a formális incidenskezelés közötti triázsfunkció, amely naplók, küszöbértékek és döntési kritériumok alapján határozza meg az eszkalációt. Az A.8.8 esetében a Zenith Controls összekapcsolja a technikai sérülékenységek kezelését a kártevők elleni védelemmel, konfigurációkezeléssel, változáskezeléssel, végpontbiztonsággal, fenyegetettségi információkkal, megfigyeléssel, biztonságos fejlesztéssel, eseményértékeléssel és incidensreagálással.

A Zenith Controls egyik része különösen hasznos, ha aktív kihasználás gyanúja merül fel:

„A fenyegetettségi információk megmutatják, mely sérülékenységeket használják ki aktívan, és ezzel irányítják a javítások priorizálását.”
Forrás: Zenith Controls: The Cross-Compliance Guide, ISO/IEC 27002:2022 8.8 kontroll, kapcsolat az 5.7 Threat Intelligence kontrollal Zenith Controls

Ez fontos irányítási szempont. A súlyosság nem csak CVSS. Egy közepes pontszámú, az Ön ágazata ellen aktívan kihasznált sérülékenység megelőzhet egy elméleti kritikus problémát egy nem kitett tesztrendszeren.

Mikor válik egy sérülékenység incidenssé

Nem minden sérülékenységi bejelentés incidens. Egy hiányzó biztonsági fejléc egy előéles környezetben nem ugyanaz, mint egy kihasznált jogosultságellenőrzés-megkerülés, amely ügyfélszámlákat tesz elérhetővé. Ugyanakkor minden hiteles sérülékenységi bejelentésnek át kell mennie incidensdöntési kapun.

A NIS2 Article 23 előírja, hogy az alapvető és fontos szervezetek indokolatlan késedelem nélkül értesítsék CSIRT-jüket vagy az illetékes hatóságot azokról az incidensekről, amelyek jelentős hatással vannak a szolgáltatásnyújtásra. Jelentős incidens az, amely súlyos működési zavart vagy pénzügyi veszteséget okozott vagy képes okozni, illetve amely másokat jelentős vagyoni vagy nem vagyoni kár okozásával érintett vagy képes érinteni. A jelentési sorrend magában foglal egy korai figyelmeztetést a tudomásszerzéstől számított 24 órán belül, egy incidensbejelentést 72 órán belül, közbenső jelentéseket kérés esetén, valamint zárójelentést a 72 órás bejelentéstől számított egy hónapon belül.

A DORA Articles 17 to 20 előírja, hogy a pénzügyi szervezetek észleljék, kezeljék, rögzítsék, osztályozzák, eszkalálják, bejelentsék és kommunikálják az IKT-val kapcsolatos incidenseket és jelentős kiberfenyegetéseket. A jelentős IKT-val kapcsolatos incidenseket a felső vezetéshez és a vezető testülethez kell eszkalálni. Ügyfélkommunikációra lehet szükség, ha pénzügyi érdekek érintettek.

KKV-k esetében a bejelentési kultúrának ugyanilyen egyértelműnek kell lennie. A Clarysec Incidenskezelési szabályzat-sme Incidenskezelési szabályzat - SME kimondja:

„A munkatársak kötelesek minden gyanús tevékenységet vagy megerősített incidenst jelenteni az incident@[company] címre, vagy szóban az ügyvezetőnek vagy az IT-szolgáltatónak.”
Forrás: Incidenskezelési szabályzat-sme, a szabályzat végrehajtásának követelményei, 6.2.1 pont

A Zenith Blueprint Controls in Action fázisának 16. lépése, People Controls II, még egyszerűbben fogalmazza meg az elvet:

„Ha kétsége van, jelentse.”
Forrás: Zenith Blueprint: An Auditor’s 30-Step Roadmap, Controls in Action fázis, 16. lépés: People Controls II (A.6.5 to A.6.8)

Ennek az elvnek a fejlesztőkre, támogatási csapatokra, beszállítókezelőkre, adatvédelmi vezetőkre, felsővezetőkre és kiszervezett szolgáltatókra egyaránt vonatkoznia kell. Az olyan sérülékenységet, amely érintheti a bizalmasságot, sértetlenséget, rendelkezésre állást, ügyfélbizalmat, szabályozott jelentéstételt vagy pénzügyi működést, rögzíteni és értékelni kell, nem pedig informális chaten kezelni.

Helyesbítő intézkedések, javítások telepítése és kompenzáló kontrollok

Amint egy sérülékenységet validáltak, kezelni kell. A kezelésnek kockázatalapúnak, bizonyítékokkal alátámasztottnak és időkorlátosnak kell lennie.

A Koordinált sérülékenység-közzétételi szabályzat meghatározza a vállalati elvárást:

„Helyesbítő intézkedési terv: Minden megerősített sérülékenységre javítási vagy kockázatcsökkentő 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 lehetőség szerint 14 napon belül, aktív kihasználás észlelése esetén pedig ennél korábban kell javítani vagy mérsékelni, míg az alacsonyabb súlyosságú problémákat észszerű időkereten belül kell kezelni. Ha a teljes javítás késik, kompenzáló kontrollokat vagy átmeneti kockázatcsökkentő intézkedéseket – például sérülékeny funkcionalitás letiltását vagy a megfigyelés fokozását – kell bevezetni.”
Forrás: Koordinált sérülékenység-közzétételi szabályzat, végrehajtási követelmények, 6.6 pont

KKV-k javításkezelési fegyelméhez a Sérülékenység- és javításkezelési szabályzat-sme Sérülékenység- és javításkezelési szabályzat - SME kimondja:

„A kritikus javításokat a kiadástól számított 3 napon belül telepíteni kell, különösen internet felől elérhető rendszerek esetében”
Forrás: Sérülékenység- és javításkezelési szabályzat-sme, a szabályzat végrehajtásának követelményei, 6.1.1 pont

Ezek a határidők nem mondanak ellent egymásnak. Egy internet felől elérhető rendszer beszállítói javítása nagyon gyors telepítést igényelhet. Egy kódmódosítást, regressziós tesztelést, ügyfélegyeztetést és szakaszos kiadást igénylő terméksérülékenységhez viszont szükség lehet köztes kockázatcsökkentéseket tartalmazó helyesbítő intézkedési tervre. A lényeg az, hogy a döntés dokumentált, kockázatgazdához rendelt és jóváhagyott legyen, ha maradványkockázat marad fenn.

Egy gyakorlati esettanulmány menete így néz ki:

1. Egy kutató jogosultságellenőrzés-megkerülést jelent az ügyfélszámlázási API-ban.
2. A VRT időbélyeggel rögzíti a CVD-2026-014 bejegyzést, és 2 munkanapon belül visszaigazolja.
3. A termékbiztonsági csapat 24 órán belül validálja a hibát, és a tenantok közötti adathozzáférés miatt Magas súlyosságot rendel hozzá.
4. Az adatvédelmi funkció GDPR szerinti adatsértési értékelést végez, mert a számlanyilvántartások személyes adatokat tartalmazhatnak.
5. Az incidensmenedzser eseményértékelést indít az ISO/IEC 27002:2022 A.5.25 kontroll alapján.
6. A rendszergazda ideiglenes feature flaggel letiltja a sérülékeny végpontot.
7. A mérnöki csapat hotfixet készít az ISO/IEC 27002:2022 A.8.32, Change management kontroll alapján.
8. A kihasználás indikátoraira megfigyelési szabályok kerülnek hozzáadásra, az A.8.15, Logging és A.8.16, Monitoring activities kontrollokhoz kapcsolva.
9. A CISO tájékoztatja a felső vezetést, mert a probléma magas kockázatú.
10. A VRT egyeztet a kutatóval az újratesztelésről és a közzététel időzítéséről.
11. A kockázatgazda csak az ellenőrző tesztek és az ügyfélhatás felülvizsgálata után hagyja jóvá a lezárást.
12. Frissül a SoA, a kockázati nyilvántartás, a jegy, a naplók, a vezetői értesítés és a tanulságok.

Ez a különbség aközött, hogy „telepítettük a javítást” és aközött, hogy „bizonyítani tudjuk, hogy irányítottan kezeltük”.

Beszállítói és felhőfüggőségek: a rejtett hibapont

Sok CVD-hiba valójában beszállítói hiba. A sérülékenység érinthet SaaS-komponenst, felhőszolgáltatást, menedzselt biztonsági szolgáltatót, fizetési átjárót, hitelesítési brókert, nyílt forráskódú könyvtárat, kiszervezett fejlesztőcsapatot vagy alvállalkozót.

A NIS2 Article 21 előírja az ellátási lánc biztonságát, beleértve a közvetlen beszállítókkal és szolgáltatókkal fennálló kapcsolatokat. Az ellátási láncra vonatkozó intézkedéseknek figyelembe kell venniük a beszállítói sérülékenységeket, a termékminőséget, a kiberbiztonsági gyakorlatokat és a biztonságos fejlesztési eljárásokat.

A DORA Articles 28 to 30 mélyebb követelményeket határoz meg a pénzügyi szervezetek számára. Előírja, hogy az IKT-val kapcsolatos harmadik fél kockázatokat az IKT-kockázati keretrendszer részeként kell kezelni, ideértve az IKT-szolgáltatási szerződések nyilvántartását, a kritikus vagy fontos funkciók megkülönböztetését, a szerződéskötés előtti kellő gondosságot, a szerződéses biztonsági követelményeket, az incidenssegítséget, a hatóságokkal való együttműködést, az auditálási jogot, a felmondási jogokat és a kilépési stratégiákat. A pénzügyi szervezetek az IKT-szolgáltató harmadik felek igénybevétele esetén is teljes mértékben felelősek maradnak a DORA-megfelelésért.

A Clarysec Harmadik fél és beszállítói biztonsági szabályzat-sme Harmadik fél és beszállítói biztonsági szabályzat - SME egyszerű eszkalációs szabályt tartalmaz:

„Minden biztonsági adatsértésről, változásról vagy incidensről haladéktalanul értesíteni kell az ügyvezetőt”
Forrás: Harmadik fél és beszállítói biztonsági szabályzat-sme, szerepkörök és felelősségek, 4.4.3 pont

Vállalati beszállítói szerződések esetében a Zenith Blueprint Controls in Action fázisának 23. lépése javasolja a titoktartási kötelezettségek, hozzáférés-szabályozási felelősségek, technikai és szervezeti intézkedések (TOM), incidensbejelentési határidők, auditálási jog, alvállalkozói kontrollok és szerződés lezárására vonatkozó rendelkezések beépítését. Így fogalmaz:

„Az számít, hogy léteznek, és hogy mindkét fél érti és elfogadja őket.”
Forrás: Zenith Blueprint: An Auditor’s 30-Step Roadmap, Controls in Action fázis, 23. lépés: Organizational controls (5.19 to 5.37)

A CVD-hez kapcsolódó beszállítói felkészültségnek választ kell adnia ezekre a kérdésekre:

• Közzétesz-e a beszállító sérülékenység-bejelentési csatornát?
• Meghatározza-e a szerződés a sérülékenységi értesítési határidőket?
• Jelentik-e indokolatlan késedelem nélkül a kritikus beszállítói sérülékenységeket?
• Kapcsolódnak-e az ügyfélhatással járó gyengeségek incidenssegítségre vonatkozó kötelezettségekhez?
• Tud-e a beszállító javítási bizonyítékot vagy biztonsági tájékoztatót biztosítani?
• Továbböröklődnek-e az alvállalkozókra a sérülékenységekkel kapcsolatos kötelezettségek?
• Van-e kilépési stratégia arra az esetre, ha a javítás nem megfelelő?

Itt találkozik a NIS2, a DORA és az ISO/IEC 27001:2022. A beszállítói sérülékenységkezelés nem beszerzési jelölőnégyzet. Az operatív reziliencia része.

Bizonyítékmegfeleltetés ISO 27001, NIS2, DORA, GDPR és COBIT szerint

A legerősebb CVD-programok bizonyítékvezéreltek. Abból indulnak ki, hogy bármely jelentős bejelentést később belső audit, tanúsítási auditorok, szabályozó hatóságok, ügyfelek, biztosítók vagy az igazgatóság kockázati bizottsága is felülvizsgálhat.

A Clarysec Audit- és megfelelésfelügyeleti szabályzat-sme Audit- és megfelelésfelügyeleti szabályzat - SME egy olyan részletet rögzít, amelyet sok csapat figyelmen kívül hagy:

„A metaadatokat (pl. ki gyűjtötte, mikor és melyik rendszerből) dokumentálni kell.”
Forrás: Audit- és megfelelésfelügyeleti szabályzat-sme, a szabályzat végrehajtásának követelményei, 6.2.3 pont

Egy javított szerverről készült képernyőkép gyenge bizonyíték, ha senki sem tudja, ki készítette, mikor, melyik rendszerből, és hogyan kapcsolódik a sérülékenységhez. Egy időbélyegeket, vizsgálati kimenetet, pull requestet, változtatás-jóváhagyást, telepítési naplókat, megfigyelési lekérdezést, újratesztelési megerősítést és metaadatokat tartalmazó jegy sokkal erősebb.

Egy részletesebb visszakövethetőségi mátrix segít az ügyfélátvilágítás és a belső audit során.

A különböző auditorok ugyanazt a folyamatot eltérő nézőpontból tesztelik.

Egy ISO/IEC 27001:2022 auditor az ISMS-sel kezdi. Megvizsgálja, hogy a sérülékenység-közzétételi kötelezettségek szerepelnek-e az érdekelt felek követelményei között, a kockázatokat következetesen értékelik-e, a kontrollok megjelennek-e a SoA-ban, van-e működési bizonyíték, és a vezetőség felülvizsgálja-e a trendeket és a lejárt tételeket.

Egy DORA- vagy pénzügyi szolgáltatási felülvizsgáló az operatív rezilienciára összpontosít. Megvizsgálja az IKT-kockázati integrációt, az incidensosztályozást, a felső vezetői eszkalációt, az ügyfélkommunikációt, a harmadik fél függőségeket, a tesztelést és a tanulságokat. Ha a sérülékenység kritikus vagy fontos funkciót érint, szoros kapcsolatot vár el a technikai jegy, az üzleti hatás, a folytonossági következmények és a beszállítói kötelezettségek között.

Egy GDPR-felülvizsgáló a személyes adatokra összpontosít. Érintett-e személyes adat? Történt-e jogosulatlan hozzáférés, elvesztés, módosítás vagy közzététel? Egyértelműek voltak-e az adatkezelői és adatfeldolgozói szerepek? Értékelték-e az adatsértési küszöböt? Relevánsak voltak-e olyan védelmi intézkedések, mint a titkosítás, hozzáférés-szabályozás, naplózás és adattakarékosság?

Egy COBIT 2019 vagy ISACA auditor az irányításra, elszámoltathatóságra, teljesítményre és bizonyosságra összpontosít. Meghatározott felelősséget, mutatókat, eszkalációt, kontrollcélokat, vezetői felügyeletet és kivételkövetést keres. Egy lejárt határidejű kritikus sérülékenység nem csupán technikai probléma. Irányítási kérdés, hacsak formálisan nem eszkalálták és nem fogadták el kockázatként.

Egy NIST-orientált értékelő az Identify, Protect, Detect, Respond és Recover funkciók mentén gondolkodik. Eszközgazdai felelősséget, sérülékenységazonosítást, priorizálást, védelmi célú változtatást, kihasználásészlelést, reagálási koordinációt és helyreállítási ellenőrzést vár.

Az integrált CVD-modell előnye, hogy ugyanaz a bizonyítéklánc mindezeket a felülvizsgálatokat támogatni tudja.

A havi kontrollkör: vezetés által használható mutatók

A CVD nem ér véget a jegy lezárásával. A Koordinált sérülékenység-közzétételi szabályzat folyamatos naplófelülvizsgálatot ír elő:

„A VRT köteles sérülékenység-közzétételi naplót vezetni, amely minden bejelentést nyomon követ az átvételtől a lezárásig. A naplót havonta felül kell vizsgálni annak biztosítására, hogy a nyitott tételek időben haladjanak. A lejárt tételeket eszkalálni kell.”
Forrás: Koordinált sérülékenység-közzétételi szabályzat, megfigyelés és audit, 9.1 pont

Ez a havi felülvizsgálat a sérülékenység-közzétételt igazgatósági szinten kezelhető irányítási folyamattá alakítja. A vezetésnek nincs szüksége minden technikai részletre. Trendre, kitettségre, elszámoltathatóságra és lejárt határidejű kockázatra van szüksége.

Egy érett Clarysec-bevezetésben ez a havi naplófelülvizsgálat táplálja a kockázati nyilvántartást, az alkalmazhatósági nyilatkozatot, a biztonságos fejlesztési backlogot, a beszállítói felülvizsgálatokat, az incidensek tanulságait, a belső audittervet és a vezetői jelentési csomagot.

Építse fel a folyamatot a súlyos bejelentés előtt

A koordinált sérülékenység-közzététel megtervezésére a legrosszabb időpont az, amikor egy kutató már nyilvánosan közzétette a gyengeséget, vagy egy kritikus banki ügyfél befagyasztotta a beléptetést. A NIS2, a DORA, a GDPR, az ISO/IEC 27001:2022, a NIST-szerű rezilienciaelvárások és a COBIT 2019 irányítási elvei mind ugyanabba az irányba mutatnak: a sérülékenység-közzétételt meg kell tervezni, gazdához kell rendelni, tesztelni kell, bizonyítékokkal kell alátámasztani és fejleszteni kell.

Kezdje ezzel az öt lépéssel:

1. Fogadja el vagy szabja testre a Koordinált sérülékenység-közzétételi szabályzatot.
2. Építse fel a bejelentés-kezelési és triázs-munkafolyamatot a Zenith Blueprint alapján, különösen a 13. lépést a SoA-visszakövethetőséghez, a 16. lépést a bejelentési kultúrához, a 19. lépést a technikai sérülékenységek kezeléséhez és a 23. lépést a beszállítói megállapodásokhoz.
3. Feleltesse meg a munkafolyamatot a Zenith Controls segítségével, az ISO/IEC 27002:2022 A.8.8, A.5.24, A.5.25, A.5.26, A.5.27, A.5.28, A.8.15, A.8.16, A.8.25 és A.8.32 kontrolljaira összpontosítva.
4. Illesszen be KKV-kra kész pontokat az Incidenskezelési szabályzat-sme, a Sérülékenység- és javításkezelési szabályzat-sme, a Harmadik fél és beszállítói biztonsági szabályzat-sme, az Alkalmazásbiztonsági követelmények szabályzata-sme és az Audit- és megfelelésfelügyeleti szabályzat-sme dokumentumokból, ahol az arányosság számít.
5. Futtasson asztali gyakorlatot, amely személyes adatokat és beszállító által hosztolt komponenst érintő kutatói bejelentést szimulál, majd tesztelje a visszaigazolást, triázst, incidensosztályozást, javítások telepítését, ügyfélkommunikációt, bizonyítékrögzítést és vezetői eszkalációt.

A Clarysec segíthet ezt működő CVD-szabályzattá, bejelentés-kezelési nyilvántartássá, ISO/IEC 27001:2022 bizonyítéktérképpé, NIS2 és DORA döntési fává, beszállítói eszkalációs modellé és auditra felkészített kontrollcsomaggá alakítani. A cél egyszerű: amikor a következő sérülékenységi bejelentés megérkezik, a csapat ne improvizáljon. Magabiztosan, bizonyítékokkal és kontrolláltan hajtsa végre a folyamatot.