ITDR-stratégia ISO 27001, NIS2, DORA és GDPR környezetben

Kedd hajnali 3:00-kor Sarah, a FinScale CISO-ja olyan riasztásra ébredt, amelytől a modern biztonsági vezetők egyre inkább tartanak. Egy vezető fejlesztő aktív, néhány órával korábban MFA-val hitelesített munkamenetét szokatlan forrásból használták éles adatbázissémák feltérképezésére.

Nem volt malware beacon. Nem volt zsarolóvírus-üzenet. Nem volt tűzfal-exploit. Csak identitás.

A SOC észlelte a tevékenységet, de a reagálás rendezetlen volt. MFA-megkerülés történt, ellopott munkamenet-tokenről volt szó, vagy maga az identitásszolgáltató kompromittálódott? Kinek volt jogosultsága az aktív munkamenet megszüntetésére? Elég volt visszavonni a jelszót, vagy a csapatnak érvénytelenítenie kellett a frissítési tokeneket, rotálnia az API-hitelesítő adatokat és felül kellett vizsgálnia az OAuth-engedélyeket is? Mire a tevékenységet sikerült elszigetelni, a támadó 47 perce volt aktív.

Másnap reggel a biztonsági incidens irányítási problémává vált. Az igazgatóság közérthető magyarázatot kért arról, hogy a FinScale kiberhigiéniája megfelelt-e a NIS2 elvárásainak. A megfelelőségi csapat azt akarta tudni, hogy az esemény DORA szerinti jelentős IKT-vonatkozású incidensnek minősíthető-e. A jogi területnek igazolható válaszra volt szüksége arról, hogy történt-e hozzáférés személyes adatokhoz a GDPR Article 32 alapján, és szükséges-e személyesadat-sértési értékelés. A külső auditor azt kérdezte, hogy az ISO/IEC 27001:2022 kontrollok ténylegesen működtek-e, nem csupán a szabályzatokban szerepeltek.

Sarah problémája nem az eszközök hiánya volt. A FinScale rendelkezett identitásszolgáltatóval, MFA-val, SIEM-mel, végponti kontrollokkal, felhőnaplókkal és incidenskezelési folyamattal. A probléma az volt, hogy az identitáskezelés, a naplózás, a felügyelet, az incidenskezelés, az adatvédelmi értékelés és a bizonyítékkezelés silókban működött.

Ez a 2026-os Identity Threat Detection and Response probléma. Az ITDR már nem pusztán biztonsági üzemeltetési képesség. Több keretrendszerre kiterjedő megfelelőségi bizonyítékmotor az ISO/IEC 27001:2022, a NIS2, a DORA és a GDPR Article 32 követelményeihez.

A Clarysec Zenith Blueprint: 30 lépéses auditütemterv Zenith Blueprint, szabályzatcsomagja és Zenith Controls: több keretrendszerre kiterjedő megfelelőségi útmutató Zenith Controls segíti a szervezeteket abban, hogy az identitásalapú támadásokat kaotikus vizsgálatok helyett ismételhető, auditálható kontrollfolyamatokba illesszék.

Miért lett az Identity Threat Detection and Response igazgatósági szintű kérdés?

Az identitásalapú támadások azért működnek, mert legitim hozzáférési útvonalakkal élnek vissza. Az a támadó, aki ellop egy munkamenet-tokent, rosszindulatú OAuth-alkalmazást regisztrál, kompromittál egy szolgáltatásfiókot, vagy MFA push fatigue módszerrel rávesz egy felhasználót a jóváhagyásra, érvényes felhasználónak tűnhet olyan rendszerek számára, amelyek csak azt ellenőrzik, hogy a hitelesítés sikeres volt-e.

Ez különbözteti meg az ITDR-t a hagyományos peremvédelemtől. Egy érett programnak képesnek kell lennie megválaszolni a következő kérdéseket:

• Milyen emberi, szolgáltatási, beszállítói és alkalmazásidentitások léteznek?
• Mely identitások emelt jogosultságúak, inaktívak, megosztottak vagy külső föderációval kapcsolódnak?
• Mely hitelesítési események normálisak, kockázatosak vagy lehetetlenek?
• Mely OAuth-engedélyek, SaaS-tokenek és API-hitelesítő adatok férhetnek hozzá érzékeny adatokhoz?
• Mely riasztások indítanak incidensbesorolást, bizonyítékmegőrzést és szabályozói döntéshozatalt?
• Mely kontrollok igazolják, hogy a személyes adatokhoz való hozzáférést megfelelő technikai és szervezési intézkedések védik?

A NIS2 ezt irányítási kérdéssé teszi. 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, működési és szervezési intézkedéseket ír elő, ideértve a kockázatelemzést, az incidenskezelést, az üzletmenet-folytonosságot, az ellátási lánc biztonságát, a kontrollhatékonyság értékelését, a kiberhigiéniát, a képzést, a hozzáférés-szabályozást, az eszközkezelést, valamint adott esetben a többtényezős vagy folyamatos hitelesítést.

A DORA hasonló nyomást helyez a pénzügyi szervezetekre. Dokumentált IKT-kockázatkezelési keretrendszert, vezető testületi felelősséget, észlelési mechanizmusokat, incidenskezelést, besorolást, jelentéstételt, rezilienciatesztelést és IKT harmadik fél kockázatkezelést ír elő. A DORA 2025. január 17-től alkalmazandó. Azoknál a pénzügyi szervezeteknél, amelyek a NIS2 hatálya alá is tartoznak, a DORA az átfedő IKT-kockázati és incidensjelentési kötelezettségek ágazatspecifikus szabályrendszereként működik.

A GDPR hozzáadja az adatvédelmi elszámoltathatósági réteget. Az Article 5 sértetlenséget, bizalmasságot és elszámoltathatóságot ír elő. Az Article 4 tágan határozza meg a személyesadat-sértést, ideértve a személyes adatokhoz való jogosulatlan hozzáférést is. Az Article 32 megfelelő technikai és szervezési intézkedéseket követel meg a kockázattal arányos biztonsági szint biztosítására. Identitásincidenseknél a naplók, hozzáférés-szabályozási kontrollok, hitelesítési nyilvántartások és incidensbizonyítékok központi szerepet kapnak annak igazolásában, hogy a személyes adatok védettek voltak-e.

Az ISO/IEC 27001:2022 az az irányítási rendszer, amely ezeket a kötelezettségeket egyben tudja tartani. A 4. pont előírja, hogy a szervezet értse meg saját környezetét, az érdekelt feleket, valamint a jogi, szabályozási és szerződéses követelményeket. A 6. pont kockázatértékelést, kockázatkezelést, a kockázattulajdonos jóváhagyását és megőrzött bizonyítékokat ír elő. Az A melléklet kontrollokat tartalmaz az identitáskezelésre, a biztonságos hitelesítésre, a naplózásra, a felügyeletre, az incidenskezelésre, a bizonyítékgyűjtésre, a beszállítói kapcsolatokra, a felhőszolgáltatásokra és a magánszféra védelmére.

Az ITDR-nek az IBIR-en belül van a helye, mert az identitáskockázat csak akkor válik auditálhatóvá, ha az alkalmazási körbe kerül, felelőse van, értékelik, kezelik, nyomon követik és fejlesztik.

Az identitásalapú támadási forgatókönyv, amely a szabályozókat érdekli

Vegyünk egy EU-s ügyfeleket kiszolgáló, felhőalapú pénzügyi munkafolyamat-szolgáltatót. Microsoft 365-öt, ügyféltámogatási SaaS-platformot, felhőinfrastruktúrát, fizetési feldolgozót és több API-alapú integrációt használ. Egy vezető támogatási mérnök meggyőző felszólítást kap egy produktivitási alkalmazás újracsatlakoztatására. Az OAuth-hozzájárulási képernyő postafiók-olvasási hozzáférést és offline hozzáférést kér. A mérnök jóváhagyja.

Perceken belül a támadó a tokennel ügyfélazonosítókra és támogatási csatolmányokra keres. Feltérképezi a csoporttagságokat, és megpróbál hozzáférni egy adminisztrációs portálhoz. Az MFA engedélyezve volt, de a támadónak nincs újra szüksége a jelszóra, mert a token tartós hozzáférést biztosít. A SOC szokatlan postafiók-hozzáférést, új OAuth-alkalmazást, sikertelen adminisztrációsportál-hozzáférési kísérleteket és szokatlan földrajzi helyről származó tevékenységet lát.

Ez az egyetlen forgatókönyv több kontrollterületet érint:

• Identitáséletciklus, mert a felhasználó szerepköre és jogosultságai határozzák meg a blast radius mértékét.
• Biztonságos hitelesítés, mert az MFA önmagában nem akadályozta meg a tokennel való visszaélést.
• Naplózás és felügyelet, mert az észlelés az identitásszolgáltató, a SaaS és az alkalmazások naplóitól függ.
• Incidenskezelés, mert a hitelesítő adatokat, munkameneteket, tokeneket és OAuth-engedélyeket gyorsan vissza kell vonni.
• Bizonyítékgyűjtés, mert személyes adatok kitettsége és szabályozói jelentéstétel következhet.
• Beszállítói és felhőirányítás, mert a SaaS-naplók és audit API-k a bizonyítéklánc részei.
• Magánszféra védelme, mert a személyes adatokhoz való hozzáférést a GDPR alapján értékelni kell.

A jobb kérdés nem az, hogy „melyik eszköz hibázott?”. A jobb kérdés az, hogy a szervezet rendelkezett-e megtervezett, tesztelt és auditálható ITDR kontroll-lánccal.

Az ISO 27001:2022 kontroll-lánc a hatékony ITDR mögött

A leghatékonyabb ITDR-programok összekapcsolják a megelőző, észlelő, helyesbítő és bizonyítékképző kontrollokat.

A Zenith Controls az ISO/IEC 27001:2022 5.16 Identitáskezelés kontrollját megelőző kontrollként kezeli, amely támogatja a bizalmasságot, a sértetlenséget és a rendelkezésre állást. Közvetlenül kapcsolódik az 5.15 Hozzáférés-szabályozás, az 5.17 Hitelesítési információk, az 5.18 Hozzáférési jogosultságok, az 5.19 Információbiztonság a beszállítói kapcsolatokban, az 5.36 Információbiztonsági szabályzatoknak, szabályoknak és szabványoknak való megfelelés, valamint a 8.2 Emelt szintű hozzáférési jogosultságok kontrollokhoz.

Ez azért fontos, mert az identitásalapú észlelés megbukik, ha az identitásirányítás gyenge. Ha egy szolgáltatásfiók nincs dokumentálva, egy beszállítói identitás nincs felügyelve, vagy egy kiemelt jogosultságú szerepkörnek nincs tulajdonosa, a felügyelet észlelhet ugyan egy eseményt, de a reagálók nem tudják gyorsan értelmezni.

A 8.5 Biztonságos hitelesítés kontroll az ITDR másik horgonykontrollja. A Zenith Controls ezt az identitáskezeléssel, a hitelesítési információkkal, a kiemelt hozzáférési jogosultságokkal, az információ-hozzáférés korlátozásával, a felügyeleti tevékenységekkel, az incidenskezeléssel és a PII magánszférájának védelmével kapcsolja össze. A hitelesítés nem ér véget a bejelentkezésnél. A munkamenet-kezelés, a tokenkezelés, a hitelesítő adatok védelme és a visszakövethetőség ugyanannak a bizonyítási láncnak a részei.

A 8.16 Felügyeleti tevékenységek kontroll a naplók gyűjtése és a döntéshozatal közötti kapcsolópont. A 8.15 Naplózás kontrollra épül, és támogatja az 5.25 Információbiztonsági események értékelése és döntés, az 5.26 Reagálás információbiztonsági incidensekre, valamint a szélesebb incidenskezelési folyamatot. Az ITDR esetében a 8.16 az a pont, ahol a gyanús identitásviselkedés triage-olt eseménnyé, bejelentett incidenssé vagy dokumentált téves pozitívvá válik.

A táblázat nem elméleti megfeleltetés. Ez az a gyakorlati bizonyítéklánc, amelyet egy auditor, igazgatósági tag vagy szabályozó elvár egy identitásincidens után.

Mit adnak hozzá a Clarysec szabályzatok: felelősség, kiváltó feltételek és bizonyítékszabályok

Az identitáseszközök önmagukban nem teremtenek elszámoltathatóságot. Válsághelyzetben a reagálóknak felhatalmazásra van szükségük munkamenetek visszavonására, fiókok letiltására, naplók exportálására, bizonyítékok megőrzésére és eszkalációs döntések meghozatalára. Az auditoroknak látniuk kell, hogy ezek az intézkedések nem rögtönzöttek voltak.

A Clarysec szabályzatcsomagja ezt a működési modellt biztosítja.

A vállalati Felhasználói fiók- és jogosultságkezelési szabályzat Felhasználói fiók- és jogosultságkezelési szabályzat 5.9 Irányítási követelmények pontja kimondja:

A szervezetnek részletes nyilvántartást kell fenntartania valamennyi aktív és inaktív hitelesítő adatról, kiemelt jogosultságú fiókról és rendszerszintű szolgáltatásfiókról. Ezt a nyilvántartást folyamatosan frissíteni kell, és negyedévente felül kell vizsgálni.

Ez az identitásnyilvántartást kifejezett kontrollkötelezettséggé teszi. Ez különösen fontos, mert a szolgáltatásfiókok, API-kulcsok és inaktív hitelesítő adatok gyakori ITDR-vakfoltok.

Ugyanez a szabályzat az 5.8 Irányítási követelmények pontban kimondja:

Minden adminisztratív tevékenységet és kiemelt jogosultságú fiókkal végzett műveletet manipuláció észlelésére alkalmas módon naplózni kell, és anomáliákra vagy szabályzatsértésekre figyelni kell.

Ez a pont összekapcsolja az emelt jogosultságú hozzáférések kezelését az észleléssel. Egy kiemelt jogosultságú művelet nem pusztán engedélyezett vagy tiltott. Meg kell figyelni, hogy a viselkedés illeszkedik-e a felhasználóhoz, szerepkörhöz, forráshoz, időponthoz vagy üzleti folyamathoz.

Kisebb szervezetek számára a Felhasználói fiók- és jogosultságkezelési szabályzat - KKV Felhasználói fiók- és jogosultságkezelési szabályzat - KKV tömör elvárást fogalmaz meg a 8.1.1 Érvényesítés és megfelelőség pontban:

Az informatikai vezetőnek rendszeresen felül kell vizsgálnia a rendszernaplókat jogosulatlan hozzáférési kísérletek, bejelentkezési rendellenességek vagy nem jóváhagyott jogosultságváltozások azonosítása érdekében.

Sok KKV ITDR-programja innen indul. Ehhez nincs szükség nagy SOC-ra. Megnevezett felelősségre és a megfelelő identitásjelek rendszeres felülvizsgálatára van szükség.

A naplózási szabályzat adja a bizonyítékok alapját. A Naplózási és felügyeleti szabályzat - KKV Naplózási és felügyeleti szabályzat - KKV az 5.4.2 Irányítási követelmények pontban meghatározza:

Hitelesítési naplók: sikeres és sikertelen bejelentkezési kísérletek, munkamenet-időtartam, MFA-használat

Ezek a mezők nem opcionálisak. Segítenek igazolni, hogy a gyanús esemény sikeres hitelesítéssel, ismételt hibákkal, MFA-használattal, tartós munkamenettel vagy rendellenes időtartammal járt-e.

A vállalati Naplózási és felügyeleti szabályzat Naplózási és felügyeleti szabályzat a 6.1.1 Szabályzat-végrehajtási követelmények pontban bővíti az előírt naplók körét:

Minden érintett rendszernek olyan naplókat kell előállítania, amelyek rögzítik: 6.1.1.1 Felhasználói hitelesítési és hozzáférési kísérletek 6.1.1.2 Kiemelt jogosultságú felhasználói tevékenységek 6.1.1.3 Konfigurációváltozások 6.1.1.4 Sikertelen hozzáférési kísérletek vagy rendszeresemények 6.1.1.5 Malware-észlelések és biztonsági riasztások 6.1.1.6 Külső kommunikáció és tűzfalszabály-kiváltások

A konfigurációváltozások különösen fontosak identitásalapú támadásoknál. A támadók gyakran adnak hozzá OAuth-engedélyeket, hoznak létre továbbítási szabályokat, regisztrálnak eszközöket, módosítanak MFA-módszereket vagy alakítanak ki vészhelyzeti hozzáférési útvonalakat.

Az incidenskezelési szabályzat ezután felhatalmazást ad a reagálóknak. A vállalati Incidenskezelési szabályzat Incidenskezelési szabályzat a 6.2.1 Szabályzat-végrehajtási követelmények pontban kimondja:

A SOC-nak haladéktalanul el kell szigetelnie az érintett rendszereket, vissza kell vonnia a kompromittálódott hitelesítő adatokat, vagy tűzfal- vagy végpontbiztonsági eszközökkel blokkolnia kell a rosszindulatú forgalmat.

A KKV Incidenskezelési szabályzat - KKV Incidenskezelési szabályzat - KKV a 4.2.2 Szerepkörök és felelősségek pontban kimondja:

Végrehajtja az elszigetelési és helyreállítási intézkedéseket, például a hozzáférés letiltásával vagy biztonsági mentések visszaállításával.

Az ITDR esetében a jelszó visszavonása nem elég. A helyreállítási forgatókönyveknek tartalmazniuk kell a fiókok letiltását, a munkamenetek visszavonását, az OAuth-engedélyek érvénytelenítését, a titkok rotációját, az MFA-módszerek alaphelyzetbe állítását és a delegált jogosultságok felülvizsgálatát.

A bizonyítékkezelés jelenti a különbséget a reagálás és az igazolhatóság között. A vállalati Bizonyítékgyűjtési és forenzikai szabályzat Bizonyítékgyűjtési és forenzikai szabályzat az 5.5 Irányítási követelmények pontban kimondja:

Minden gyűjtött bizonyítékot egyedileg azonosítani, címkézni és biztonságos adattárban kell tárolni, amely tartalmazza: 5.5.1 Sértetlenség-ellenőrzés, például SHA-256 hash értékek 5.5.2 Időbélyeggel ellátott hozzáférési naplók 5.5.3 Minden gondnok által aláírt bizonyítéklánc-bejegyzések

A KKV Bizonyítékgyűjtési és forenzikai szabályzat - KKV Bizonyítékgyűjtési és forenzikai szabályzat - KKV a 6.1.1 Szabályzat-végrehajtási követelmények pontban kimondja:

Mindig forenzikus másolatot vagy exportot kell készíteni; az eredeti bizonyítékot soha nem szabad közvetlenül szerkeszteni.

A FinScale-forgatókönyvben ez azt jelenti, hogy a SOC az identitásszolgáltatói naplókat, SaaS auditnaplókat, postafiók-hozzáférési bejegyzéseket, OAuth-hozzájárulási bejegyzéseket, munkamenet-visszavonási bejegyzéseket és SIEM-riasztásokat sértetlenségvédelemmel és bizonyítéklánccal rendelkező bizonyítéktárba exportálja.

Az ITDR-ütemterv felépítése a Zenith Blueprint segítségével

A Zenith Blueprint a kontroll-láncot végrehajtási lépésekre fordítja le.

A Controls in Action szakasz 19. lépése, Technológiai kontrollok I, közvetlenül fogalmaz a hitelesítésről:

Ahol lehetséges, kerülni kell a kizárólag jelszavas hitelesítést, különösen adminisztratív fiókok, felhőkonzolok, távoli hozzáférési eszközök és minden internetnek kitett rendszer esetében. Az MFA — második tényezőként például hardverkulccsal, mobilalkalmazással vagy biometrikus azonosítással — ma már alapkövetelmény, nem luxus. Mérsékli a hitelesítő adatok ellopásának, az adathalászatnak és a brute-force támadásoknak a kockázatát.

Ugyanez a lépés túlmutat a jelszavakon. Előírja a hitelesítési adatok biztonságos tárolását és továbbítását, az API-tokenek, munkamenet-azonosítók és OAuth-hitelesítő adatok biztonságos kezelését, a gép–gép hitelesítéshez használt titokkezelést, a tokenrotációt, a munkamenet-élettartam kontrolljait, a biztonságos cookie-jelzőket és a hitelesítési naplók felülvizsgálatát.

A 22. lépés, Szervezeti kontrollok, formálisan rendezi a hozzáférési életciklust. Útmutatást ad a csapatoknak a provisioning és deprovisioning HR-rel való integrálásához, dokumentált negyedéves hozzáférés-felülvizsgálatok végrehajtásához, az identitástípusok — például egyéni, megosztott és szolgáltatásfiókok — meghatározásához, az MFA kikényszerítéséhez a kiemelt jogosultságú fiókoknál, az inaktív fiókok megszüntetéséhez és a szolgáltatási hitelesítő adatok rotációjához.

A 19. lépés a naplózás fejlesztési útját is megadja: a kritikus naplók továbbítása SIEM-be vagy naplógyűjtőbe, a megőrzés ellenőrzése, egy friss esemény visszakövetése naplók alapján, a naplók sértetlenségi funkcióinak dokumentálása, valamint a sikertelen bejelentkezésekre vagy jogosultságkiterjesztésekre vonatkozó riasztások megerősítése. Az időszinkronizálás fontos, mert az incidens rekonstrukciója megbukik, ha az identitásszolgáltató, a SaaS, a végpont és a felhőnaplók időbélyegei eltérnek.

A 23. lépés, Szervezeti kontrollok az 5.19 és 5.37 közötti kontrollokhoz, ellenőrzi az incidenskezelési képességeket. Naprakész incidenskezelési tervet, meghatározott bejelentésköteles eseményeket, asztali gyakorlatokat, dokumentált döntéseket, kommunikációs bejegyzéseket, levont tanulságokat és forenzikus bizonyítékmegőrzést — például napló-pillanatképeket, biztonsági mentéseket és biztonságos elkülönítést — követel meg.

Egy pragmatikus Clarysec ITDR-sorrend így néz ki:

1. Az identitástípusok és tulajdonosok meghatározása.
2. A hitelesítés, tokenek és munkamenetek védelme.
3. Hitelesítési, jogosultsági és SaaS-naplók gyűjtése.
4. Kockázatos viselkedés felügyelete.
5. Eseményből incidenssé minősítési döntési szabályok meghatározása.
6. Bizonyítékok megőrzése.
7. Jelentés, helyreállítás és fejlesztés.

Egyhetes ITDR bizonyítékcsomag

Egy fókuszált „identitásincidens-bizonyítékcsomag” az egyik leggyorsabb módja a hiányosságok feltárásának. Válasszon ki egy magas kockázatú forgatókönyvet, például: „Egy kiemelt jogosultságú SaaS-felhasználó hozzájárulást ad egy jogosulatlan OAuth-alkalmazásnak, és a tokent ügyféladatok elérésére használják.”

Ezután építse fel a bizonyítékcsomagot egy hét alatt.

Tartalmazzon legalább egy tényleges visszakövetést. Vegyen egy ártalmatlan, friss bejelentkezési rendellenességet, és mutassa be, hogyan jut el a csapat a riasztástól a felhasználói identitásig, eszközig, forrás IP-címig, MFA-módszerig, munkamenet-időtartamig, elért SaaS-erőforrásokig, érintett adatokig és elszigetelési döntésig. Ha a szervezet ezt a láncot asztali gyakorlaton nem tudja rekonstruálni, valós incidens során nehézségei lesznek.

A kimenet újrahasznosítható bizonyítékká válik ISO/IEC 27001:2022 belső auditokhoz, DORA IKT-incidensfolyamat-teszteléshez, NIS2 kiberhigiéniai felügyelethez és GDPR elszámoltathatósághoz.

Az ITDR megfeleltetése a NIS2, DORA és GDPR Article 32 követelményeinek

Az egységes ITDR-modell ereje abban áll, hogy ugyanaz a bizonyíték több kötelezettséget is kielégít, miközben tiszteletben tartja az egyes keretrendszerek saját nyelvezetét.

A NIS2 Article 21 kockázatalapú, arányos technikai, működési és szervezési intézkedéseket vár el. Az ITDR esetében ez hozzáférés-szabályozást, eszközkezelést, kiberhigiéniát, képzést, incidenskezelést, kontrollhatékonyság-értékelést, valamint adott esetben MFA-t vagy folyamatos hitelesítést jelent. Az Article 23 lépcsőzetes jelentéstételt ír elő jelentős incidensekre, ideértve a 24 órán belüli korai figyelmeztetést, a 72 órán belüli incidensbejelentést és az egy hónapon belüli zárójelentést.

A DORA Articles 8 to 14 előírja az IKT-eszközök és függőségek azonosítását, a védelmet és megelőzést, az észlelési mechanizmusokat, a folytonosságot és helyreállítást, valamint a tanulást és kommunikációt. Az Articles 17 to 19 incidenskezelést, gyökérok-azonosítást, korai figyelmeztető indikátorokat, súlyosság és szolgáltatáskritikusság szerinti besorolást, eszkalációt, vezető testületi értesítést, illetékes hatósági jelentéstételt és ügyfélértesítést ír elő, ha pénzügyi érdekek érintettek.

A GDPR megfelelő technikai és szervezési intézkedéseket, valamint igazolható elszámoltathatóságot követel meg. Identitásalapú támadásoknál a GDPR-kérdések közé tartozik, hogy történt-e jogosulatlan hozzáférés, milyen személyes adatok voltak érintettek, működtek-e a védelmi intézkedések, és aktiválódtak-e az incidensbejelentési küszöbértékek.

Fintech vállalatoknál a NIS2 és a DORA kapcsolata fontos. A DORA az alkalmazási körébe tartozó pénzügyi szervezeteknél ágazatspecifikus keretrendszerként kezelendő ott, ahol átfedő IKT-kockázati és incidensjelentési kötelezettségek vannak. A gyakorlatban a szervezeteknek egyetlen ITDR-bizonyítékmodellt kell kialakítaniuk, és a jelentéstételi döntéseket az alkalmazandó jogi útvonalhoz kell megfeleltetniük.

SaaS-, felhő-, menedzselt szolgáltatási, menedzselt biztonsági és digitális platformot működtető szervezeteknél a NIS2 alkalmazási körét gondosan ellenőrizni kell. A NIS2 számos Annex I és Annex II ágazatot lefed, ideértve a digitális infrastruktúrát, felhőszolgáltatókat, adatközpontokat, bizalmi szolgáltatásokat, DNS-t, TLD-nyilvántartásokat, menedzselt szolgáltatókat, menedzselt biztonsági szolgáltatókat, online piactereket, keresőmotorokat és közösségi hálózati platformokat. Az ISO/IEC 27001:2022 4. pont szerinti alkalmazási kör meghatározása és érdekelt fél elemzése ezért nem papírmunka. Ezek határozzák meg, hogy az IBIR-nek mely kötelezettségeket kell kezelnie.

Beszállítói és SaaS identitáskockázat

Az identitásincidensek gyakran beszállítói bizonyítékoktól függenek. Tud-e a SaaS-szolgáltató auditnaplókat exportálni? Mutatja-e az OAuth-hozzájárulási eseményeket? Támogatja-e a biztonságos hozzáférés-szabályozást, naplózást és adatvédelmi képességeket? Szerződésben rendezettek-e az incidenshez nyújtott támogatás, az adattárolás helye, az alvállalkozás, a hozzáférési jogok és a kilépési rendelkezések?

A Clarysec Cloud Usage Policy - SME Cloud Usage Policy - SME az 5.2.4 Irányítási követelmények pontban közvetlen követelményt tartalmaz:

A szolgáltatás biztonságos hozzáférés-szabályozási, naplózási és adatvédelmi képességeket biztosít

Ez az egyszerű mondat beszerzési kontroll. Ha egy SaaS-platform nem tudja előállítani az incidenskezeléshez szükséges identitásnaplókat, megfelelőségi kockázatot teremt.

A DORA ezt kifejezetten kimondja az IKT harmadik fél kockázati kötelezettségeken keresztül. A pénzügyi szervezetek továbbra is felelősek a megfelelésért, fenn kell tartaniuk az IKT-szolgáltatási szerződések nyilvántartását, meg kell különböztetniük a kritikus vagy fontos funkciókat, kellő gondossággal kell eljárniuk, értékelniük kell a koncentrációs kockázatot, bele kell foglalniuk az auditálási és hozzáférési jogokat, meg kell határozniuk az incidenshez nyújtott támogatást, és biztosítaniuk kell a kilépési stratégiákat.

A Zenith Controls az ISO/IEC 27001:2022 8.16 Felügyeleti tevékenységek kontrollját az 5.22 Beszállítói szolgáltatások felügyelete, felülvizsgálata és változáskezelése kontrollhoz kapcsolja. Ez a működési valóságot tükrözi. Az identitásszolgáltatói riasztások, SaaS auditnaplók, felhőadminisztrátori tevékenységek és menedzselt szolgáltatói fiókok mind az ITDR-felület részét képezik.

Hogyan értékelik az auditorok az ITDR-t?

Egy erős ITDR-programnak több auditnézőpontból is meg kell állnia. Minden érintett más kérdéseket tesz fel, de a bizonyítékoknak ugyanabból a kontrollrendszerből kell származniuk.

Egy ISO/IEC 27001:2022 auditor meg fogja kérdezni, hogy az identitásfenyegetések szerepelnek-e a kockázatértékelésben, a kockázattulajdonosok jóváhagyták-e a kezelést, az alkalmazhatósági nyilatkozat tartalmazza-e a releváns A melléklet szerinti kontrollokat, a szabályzatokat végrehajtották-e, és a bizonyítékok igazolják-e a kontrollok működését. Mintavételezhet egy kiemelt jogosultságú fiókot, és végigkövetheti a jóváhagyást, az MFA-beállítást, a naplótevékenységet, a hozzáférés-felülvizsgálatot és a jogosultságmegszüntetést.

Egy NIST CSF 2.0 értékelő a GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND és RECOVER eredményeket vizsgálja. Az ITDR természetesen illeszkedik egy identitáskompromittálódásra, SaaS-token visszaélésre vagy kiemelt jogosultságú hozzáféréssel való visszaélésre szűkített profilba.

Egy DORA-vizsgáló a vezető testületi elszámoltathatóságot, az IKT által támogatott üzleti funkciókat, az észlelési mechanizmusokat, az incidensbesorolási kritériumokat, az eszkalációt, az ügyfélkommunikációs szabályokat, a gyökérok-elemzést és az IKT harmadik fél függőségeket keresi.

Egy GDPR-felülvizsgáló azt kérdezi, hogy a szervezet képes-e igazolni a személyes adatok megfelelő biztonságát. Vizsgálni fogja a hozzáféréskorlátozást, a jogosulatlan hozzáférés észlelését, azokat a naplókat, amelyek megmutatják, milyen adatokhoz férhettek hozzá, a személyesadat-sértési értékelést és az elszámoltathatósági bizonyítékokat.

Egy COBIT 2019 vagy ISACA-stílusú auditor az irányítást, a kontrollcélokat, a felelősséget, a teljesítményfigyelést és a bizonyosságot vizsgálja.

A Zenith Controls azért hasznos, mert több keretrendszerre kiterjedő megfelelőségi útmutatóként működik. Nem hoz létre külön „Zenith kontrollokat”. Az ISO/IEC 27001:2022 kontrollterületeket kapcsolja össze kapcsolódó ISO-kontrollokkal, más szabványokkal, auditelvárásokkal és végrehajtási összefüggésekkel.

Mutatók, amelyek igazolják, hogy az ITDR működik

Az igazgatóságoknak és auditoroknak nincs szükségük nyers SIEM-zajra. Olyan bizonyítékra van szükségük, amely megmutatja, hogy az identitáskontrollok működnek és javulnak. Hasznos ITDR-mutatók például:

• A kiemelt jogosultságú fiókok aránya, amelyek adathalászatnak ellenálló MFA-t használnak.
• A szabályzatban meghatározott küszöbértéknél régebbi inaktív fiókok száma.
• Tulajdonos vagy rotációs dátum nélküli szolgáltatásfiókok száma.
• Azon kritikus SaaS-platformok aránya, amelyek hitelesítési naplókat küldenek a SIEM-be.
• A gyanús identitástevékenység észlelésig eltelt átlagos ideje.
• A kompromittálódott munkamenetek és tokenek visszavonásáig eltelt átlagos idő.
• Jóváhagyott, elutasított vagy eltávolított OAuth-alkalmazások száma.
• Teljes bizonyítékcsomaggal rendelkező identitásincidensek aránya.
• Lejárt határidejű hozzáférés-felülvizsgálati megállapítások száma.
• Előírt identitásnaplókkal nem rendelkező beszállítói platformok száma.

Ezeket a mutatókat be kell csatornázni az ISO/IEC 27001:2022 vezetőségi átvizsgálásba, a NIS2 irányítási felügyeletbe, a DORA IKT-kockázati jelentéstételbe és a GDPR elszámoltathatósági egyeztetésekbe.

Gyakori ITDR auditmegállapítások és javítások

A Clarysec rendszeresen öt visszatérő megállapítást lát.

Először: a szervezetek engedélyezik az MFA-t, de nem figyelik az MFA-viselkedést. Javítás: naplózni kell az MFA-módszerek módosítását, a sikertelen kihívásokat, a lehetetlen utazást, az új eszközregisztrációt és az ismételt push-kísérleteket.

Másodszor: a szolgáltatásfiókok kimaradnak az identitásirányításból. Javítás: nyilvántartásba kell venni a rendszerszintű fiókokat, tulajdonosokat kell kijelölni, rotálni kell a titkokat, el kell távolítani a beágyazott hitelesítő adatokat, és figyelni kell a rendellenes API-viselkedést.

Harmadszor: a SaaS-hozzájárulás nincs felügyelve. Javítás: korlátozni kell a felhasználói hozzájárulást, felül kell vizsgálni az OAuth-alkalmazásokat, figyelni kell az új engedélyeket, dokumentálni kell a jóváhagyott integrációkat és el kell távolítani a nem használt alkalmazásokat.

Negyedszer: a bizonyíték a vizsgálat során módosul. Javítás: követni kell a Bizonyítékgyűjtési és forenzikai szabályzat szabályát: forenzikus másolatokat vagy exportokat kell készíteni, az eredetiket soha nem szabad közvetlenül szerkeszteni, és a bizonyítékokat hashekkel és bizonyítéklánc-bejegyzésekkel kell tárolni.

Ötödször: az incidensbesorolás túl lassú. Javítás: előre meg kell határozni az identitásevent-küszöbértékeket, ideértve a kiemelt jogosultságú fiókok kompromittálódását, a személyes adatokhoz való hozzáférést, az ügyfeleket érintő SaaS-token visszaélést, a kritikus szolgáltatás megszakadását és a beszállítói identitás kompromittálódását.

Minden megállapításhoz tartozik kontroll-, szabályzati és bizonyítékválasz. Ez az egységes ITDR-program gyakorlati értéke: meghatározza, minek kell felelősének lennie, mit kell felügyelni, tesztelni, bizonyítani és fejleszteni.

Alakítsa az identitáskockázatot auditkész bizonyítékká

Ha holnap történne a következő identitásincidens, igazolni tudná, ki mihez fért hozzá, hogyan hitelesített, melyik tokent vagy munkamenetet használták, milyen adatokat érintettek, ki döntött a szabályozói besorolásról, és mely helyesbítő intézkedések fejeződtek be?

Ha a válasz bizonytalan, kezdjen fókuszált ITDR-felkészültségi sprinttel.

Használja a Zenith Blueprint megoldást a végrehajtási út strukturálására a hitelesítés, hozzáférési életciklus, naplózás, felügyelet, incidenskezelés és bizonyítékkezelés területén. Használja a Clarysec hozzáférés-szabályozási, naplózási, felhő-, incidenskezelési és forenzikai szabályzatait a felelősség és a reagálási felhatalmazás kijelölésére. Használja a Zenith Controls megoldást az identitáskezelés, a biztonságos hitelesítés és a felügyeleti tevékenységek ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 és auditelvárások szerinti megfeleltetésére.

A cél egyszerű: az identitásalapú támadások legyenek észlelhetők, elszigetelhetők, jelenthetők és igazolhatók.

A Clarysec segíthet ITDR bizonyítékcsomag kialakításában, annak asztali forgatókönyvön keresztüli tesztelésében, valamint a megállapítások olyan kockázatkezelési tervvé alakításában, amelyet az igazgatóság, a szabályozó és az auditor is megért. Kezdje a Naplózási és felügyeleti szabályzat, a Felhasználói fiók- és jogosultságkezelési szabályzat - KKV, a Zenith Blueprint és a Zenith Controls áttekintésével, majd ütemezzen ITDR-felkészültségi értékelést, hogy az identitáskockázat auditkész bizonyítékká váljon.