MDR-szolgáltatók felügyelete NIS2-, DORA- és GDPR-megfeleléshez

Hétfő hajnalban, 02:13-kor az MDR-szolgáltató magas súlyosságú riasztást nyit: lehetetlen utazás, gyanús postafiókszabályok, valamint egy felügyelet nélküli végpontról használt emelt jogosultságú fiók. A SOC-elemző a jegykezelő portálon keresztül eszkalál. Az informatikai vezető alszik. A pénzügyi igazgató adathalászati figyelmeztetést kap egy banki kapcsolattartótól, mielőtt a belső incidenscsatorna aktiválódna. 07:30-ra az információbiztonsági vezető három kellemetlen kérdéssel szembesül.

Kinek volt hatásköre incidenst bejelenteni?

Igazolni tudjuk-e, hogy az MDR-szolgáltató rendelkezett a megfelelő naplókkal, azokat elég ideig megőrizte, és a bizonyítékokat megóvta?

Ha személyes adatokhoz fértek hozzá, a jogi terület képes-e tartani a GDPR szerinti adatsértés-értékelési határidőket, miközben az üzemeltetés előkészíti a NIS2 vagy DORA szerinti jelentéstételt?

Egy hónappal később a külső auditor ugyanazokat a bizonyítékokat kéri, más hangnemben. Az MDR-szolgáltató PDF-jelentése hasznos, de nem elég. Az auditor nyers riasztási adatokat, teljes naplófájlokat, az eszkalációs útvonalat, a belső döntési naplót, a beszállítói felülvizsgálat bejegyzését és annak bizonyítékát kéri, hogy a szervezet önállóan is ellenőrizni tudta a történteket.

Ez a 2026-os MDR-szolgáltatói felügyelet problémája. A szervezetek azért szervezik ki az észlelést és a reagálást, mert a belső SOC-kapacitás költséges, a munkaerő-felvétel nehéz, a fenyegetési aktivitás pedig folyamatos. A kiszervezett észlelés azonban nem jelent kiszervezett elszámoltathatóságot. NIS2 alapján a vezető testületek továbbra is felelősek a kiberbiztonsági kockázatkezelési intézkedések jóváhagyásáért és felügyeletéért. DORA alapján a pénzügyi szervezetek teljes mértékben felelősek az IKT-harmadikfél-kockázatért, ideértve a kritikus IKT-szolgáltatásokat, az incidens-támogatást, az auditálási jogokat, az alvállalkozásba adást és a kilépést. GDPR alapján az adatkezelőknek igazolniuk kell az adatkezelés megfelelő biztonságát, különösen akkor, ha adatfeldolgozók telemetriát, végponti adatokat, felhasználói azonosítókat, IP-címeket, e-mail-tartalmat, naplókat vagy forenzikus rendszerképeket kezelnek.

A gyakorlati hiányosság ritkán maga az MDR-szerződés. Inkább a szerződés és az éles szolgáltatás közötti bizonyítéklánc: a riasztások útválasztása, az emelt jogosultságú hozzáférés, a naplómegőrzés, az eszkalációs küszöbértékek, az incidensbizonyítékok, az alvállalkozói átláthatóság, az adatfeldolgozói kikötések, a szolgáltatás-felülvizsgálatok, az asztali gyakorlatok és a vezetői jelentéstétel.

Egy igazolható MDR-szolgáltatói felügyeleti programnak egységes működési modellre van szüksége, amely többféle auditbeszélgetést is kiszolgál. Ezt a gerincet az ISO/IEC 27001:2022 adja.

Az MDR-felügyelet az elszámoltathatósággal kezdődik, nem a SOC-konzollal

Gyakori hiba az MDR-bevezetést technikai projektként kezelni: EDR-ügynökök telepítése, identitásnaplók továbbítása, riasztások konfigurálása, Teams- vagy Slack-csatorna egyeztetése, majd éles indulás. Ez javíthatja az észlelést, de nem igazolja az irányítást.

A NIS2 ezt egyértelművé teszi. Az alapvető és fontos szervezeteknek megfelelő és arányos műszaki, operatív és szervezési kiberbiztonsági kockázatkezelési intézkedéseket kell bevezetniük. Article 21 kiterjed a kockázatelemzésre, az incidenskezelésre, az üzletmenet-folytonosságra, az ellátási lánc biztonságára, a kiberhigiéniára, a hozzáférés-szabályozásra, az eszközkezelésre, a kriptográfiára és a többtényezős hitelesítésre. Article 20 ezt vezető testületi elszámoltathatósági szintre emeli, és előírja ezen intézkedések jóváhagyását és felügyeletét.

Az MDR-szolgáltatók gyakran egyszerre több NIS2 Article 21 területet érintenek:

• Incidenskezelés, mert a szolgáltató triázst végez, eszkalál, és elszigetelést javasolhat.
• Ellátási lánc biztonsága, mert a szolgáltató közvetlen szolgáltató, amely hatással van az üzemeltetés biztonságára.
• Hozzáférés-szabályozás, mert a szolgáltató hozzáférhet konzolokhoz, naplókhoz, végponti eszközökhöz vagy felhőbérlőkhöz.
• Naplózás és felügyelet, mert az észlelés a naplólefedettségtől, a megőrzéstől és a korrelációtól függ.
• Kiberhigiénia, mert az MDR-megállapítások gyakran javításkezelési, identitáskezelési vagy konfigurációs gyengeségeket tárnak fel.
• Üzletmenet-folytonosság, mert a késedelmes reagálás megzavarhatja a kritikus szolgáltatásokat.

Pénzügyi szervezetek esetében a DORA tovább szigorítja a működési modellt. A DORA 2025. január 17-től alkalmazandó, és IKT-kockázatkezelést, incidensjelentést, rezilienciatesztelést, információmegosztást és IKT-harmadikfél-kockázatkezelést ír elő. Azt is egyértelművé teszi, hogy a NIS2 hatálya alá is tartozó pénzügyi szervezetek esetében a DORA az átfedő kiberbiztonsági kötelezettségek tekintetében ágazatspecifikus uniós jogi aktusként működik. Egy szabályozott bank, pénzforgalmi intézmény, befektetési vállalkozás, biztosító vagy kriptoeszköz-szolgáltató nem mondhatja egyszerűen azt, hogy „ezt az MDR-szolgáltatónk kezeli”. A DORA elvárja, hogy a szervezet besorolja az IKT-incidenseket, kezelje és felügyelje az IKT-szolgáltatásokat nyújtó harmadik feleket, vezesse az IKT-szolgáltatási megállapodások nyilvántartását, meghatározza a szerződéses jogokat, tesztelje a rezilienciát, gyökérok-elemzést végezzen, és szakaszosan jelentse a jelentős IKT-vonatkozású incidenseket.

A GDPR más szempontot ad hozzá. Ha az MDR-telemetria felhasználói azonosítókat, IP-címeket, e-mail-metaadatokat, hitelesítési bejegyzéseket, végponti artefaktumokat vagy személyes adatokat tartalmazó fájlokat foglal magában, akkor a GDPR biztonsági és elszámoltathatósági elvei alkalmazandók. Article 5 tartalmazza a sértetlenséget, a bizalmasságot és az elszámoltathatóságot. Article 32, vagyis az adatkezelés biztonsága gyakorlati bizonyítékkérdéssé válik: védettek voltak-e a naplók, korlátozott volt-e a hozzáférés, alkalmaztak-e titkosítást ott, ahol indokolt, irányítás alatt álltak-e az adatfeldolgozók, és a szervezet igazolni tudja-e, mi történt?

Az üzenet mindhárom szabályozási környezetben azonos: a munkát delegálhatja, a felelősséget nem.

Az ISO/IEC 27001:2022 auditálható folyamattá alakítja az MDR-t

Egy jól bevezetett, ISO/IEC 27001:2022 alapú IBIR az MDR-szolgáltatói felügyeletet beszállítókezelési ígéretből bizonyítékokon alapuló működési modellé alakítja. Clause 8.1 különösen fontos, mert előírja, hogy a szervezeteknek ellenőrzés alatt kell tartaniuk az IBIR szempontjából releváns, külső fél által biztosított folyamatokat, termékeket és szolgáltatásokat. Az MDR pontosan ilyen: külső fél által biztosított folyamat, amely befolyásolhatja az incidensreagálást, az adatvédelmet, a rezilienciát, a szabályozói jelentéstételt és az üzletmenet-folytonosságot.

Az MDR-felügyelet szempontjából az ISO/IEC 27001:2022 Annex A legfontosabb területei a beszállítói kapcsolatok, a beszállítói megállapodásokban rögzített biztonsági követelmények, az IKT-ellátási lánc kockázatkezelése, a beszállítói szolgáltatások felügyelete, az incidenskezelés, a bizonyítékkezelés, a naplózás, a felügyelet, a hozzáférés-szabályozás, az emelt jogosultságú hozzáférés, a kriptográfia és az üzletmenet-folytonossági felkészültség.

A Clarysec Zenith Controls: The Cross-Compliance Guide Zenith Controls ehhez a munkához a keresztmegfelelési referencia. Az ISO/IEC 27002:2022 kontrollokat más követelményekhez, kapcsolódó kontrollokhoz, audit elvárásokhoz és bevezetési bizonyítékokhoz rendeli. MDR-felügyelethez három ISO/IEC 27002:2022 kontroll központi jelentőségű: az 5.19 a beszállítói kapcsolatokhoz, az 5.22 a beszállítói szolgáltatások felügyeletéhez és a változáskezeléshez, valamint a 8.15 a naplózáshoz. Ezeket támogatja az 5.20 beszállítói megállapodások, az 5.21 IKT-ellátási lánc biztonsága, az 5.24–5.28 incidenskezelés és bizonyítékkezelés, az 5.34 adatvédelem és PII, az 5.36 megfelelés, a 8.16 monitorozási tevékenységek, a 8.17 óraszinkronizálás, a 8.18 emelt jogosultságú segédprogramok használata és a 8.8 műszaki sérülékenységek kezelése.

Ez azért lényeges, mert egy MDR-auditkudarc ritkán azt jelenti, hogy „nincs MDR”. Általában ezek valamelyikét jelenti:

• Az MDR-szolgáltatót nem sorolták kritikusnak.
• A szerződéses kikötések nem tartalmaztak incidensértesítést, bizonyítékhozzáférést vagy auditálási jogokat.
• A naplókat nem őrizték meg elég ideig egy bejelentett esemény kivizsgálásához.
• A szolgáltatói hozzáférés megosztott, tartós vagy nem felügyelt volt.
• Az ügyfél nem vizsgálta felül az MDR-teljesítményt az SLA-khoz képest.
• Az alvállalkozókat vagy al-adatfeldolgozókat nem hagyták jóvá.
• A személyesadat-sértés bejelentésére vonatkozó kötelezettségeket nem hangolták össze az incidens-munkafolyamatokkal.
• A bizonyítékokat nem forenzikusan hasznos módon őrizték meg.
• A vezetésnek nem voltak olyan mutatói, amelyek megmutatták volna, hogy az MDR-szolgáltatás csökkentette-e a kockázatot.

A Zenith Controls világosan fogalmazza meg a beszállítói elvárások és megállapodások kapcsolatát:

„Az 5.19 meghatározza a biztonsági elvárásokat arra vonatkozóan, hogyan kell a beszállítóknak kezelniük a szervezeti információkat. Az 5.20 ezeket az elvárásokat formálissá teszi azáltal, hogy biztosítja: a szerződések vagy megállapodások kifejezetten tartalmazzanak biztonsági kikötéseket, például titoktartási követelményeket, a biztonsági szabályzatoknak való megfelelést és incidensértesítési eljárásokat. Az 5.20 nélkül az 5.19-ben azonosított követelmények jogilag nem feltétlenül érvényesíthetők.”

MDR esetében ez a mondat az irányítási tanulság. Ha a szerződés nem írja elő a szolgáltató számára a naplók megőrzését, bizonyítékok rendelkezésre bocsátását, az incidensekben való együttműködést, az alvállalkozásba adás korlátozását, az auditok támogatását és az eszkalációs határidők betartását, akkor a SOC-szolgáltatás üzemeltetésileg hasznos lehet, de audit szempontból gyenge.

Mit kell igazolnia az MDR-szerződésnek az első riasztás előtt

Egy jó MDR-szerződés nem pusztán kereskedelmi megrendelőlap. Kontroll-dokumentum. A DORA Articles 28 to 30 előírja az IKT-harmadikfél-kockázat teljes életcikluson át történő kezelését, ideértve az IKT-szerződések nyilvántartását, a kritikussági besorolást, a szerződéskötés előtti kellő gondosságot, az audit- és vizsgálati megközelítéseket, a felmondási jogokat, a kilépési stratégiákat, az egyértelmű szolgáltatásleírásokat, a szolgáltatási szinteket, a szolgáltatásnyújtás és adatkezelés helyeit, az adatvédelmi vállalásokat, az incidens-támogatást és a hatóságokkal való együttműködést. NIS2 Article 21 az ellátási lánc biztonságát írja elő a közvetlen beszállítók és szolgáltatók tekintetében. A GDPR adatkezelői és adatfeldolgozói szerepköröket, adatfeldolgozói garanciákat, adatvédelmi kikötéseket és az adatkezelés biztonságára vonatkozó bizonyítékokat követel meg.

A Clarysec szabályzattára ezeket a kötelezettségeket gyakorlati szerződéses és működési követelményekké alakítja. Az Enterprise Incident Response Policy Incidenskezelési szabályzat kifejezetten irányított, harmadik fél által biztosított incidenskezelési képességként kezeli az MDR-t:

„A harmadik fél szolgáltatásokkal, ideértve a menedzselt észlelési és reagálási szolgáltatást (MDR), a biztonsági incidens- és eseménykezelést (SIEM), valamint a forenzikus elemzést nyújtó szolgáltatókat, való integrációt egyértelműen meghatározott szolgáltatási szint megállapodásoknak (SLA-k) és titoktartási rendelkezéseknek kell szabályozniuk.”

Ez a kikötés azért fontos, mert az MDR-szolgáltatók gyakran már azelőtt rendkívül érzékeny információkhoz jutnak, hogy a szervezet tudná, bejelentésköteles-e az incidens. A telemetria tartalmazhat felhasználóneveket, fájlútvonalakat, e-mail-tárgyakat, belső hosztneveket, IP-címeket, hálózati diagramokat és kompromittálódás indikátorait. A titoktartási rendelkezések védik a szervezetet a kivizsgálás során, és támogatják a GDPR szerinti elszámoltathatóságot.

Az Enterprise Third party and supplier security policy Harmadik fél és beszállítói biztonsági szabályzat két olyan kikötéssel egészíti ki ezt, amelyet az auditorok MDR-felügyelet vizsgálatakor elvárnak:

„Auditálási, vizsgálati és biztonsági bizonyítékkérésre vonatkozó jogok”

és:

„Alvállalkozók igénybevétele előzetes írásbeli hozzájáruláshoz kötötten”

KKV-k esetében ugyanez az irányítási elv kisebb léptékben érvényesül, de nem szűnik meg. A Third-Party and Supplier Security Policy - SME Harmadik fél és beszállítói biztonsági szabályzat - KKV előírja a legkisebb jogosultság elvét:

„A beszállítók csak azokhoz a minimálisan szükséges rendszerekhez és adatokhoz kaphatnak hozzáférést, amelyek a feladatuk ellátásához szükségesek.”

Továbbá előírja:

„A további alvállalkozásba adás korlátozása jóváhagyás nélkül”

Ezek a kikötések különösen relevánsak MDR esetében. Sok szolgáltató többszintű SOC-csapatokat, platformszolgáltatókat, fenyegetésintelligencia-partnereket, felhőalapú elemzési szolgáltatásokat vagy regionális támogatói személyzetet alkalmaz. Ha az alsóbb szintű felek hozzáférhetnek ügyfélnaplókhoz vagy személyes adatokhoz, az ügyfélnek átláthatóságra és jóváhagyási mechanizmusokra van szüksége. DORA szempontból ez az alvállalkozásba adás és a koncentrációs kockázat felügyeletének része. GDPR szempontból al-adatfeldolgozói irányítás. NIS2 szempontból az ellátási lánc kockázatkezelése.

Az alapvető MDR-felügyeleti ellenőrzőlista

Egy igazolható MDR-szolgáltatói kapcsolatnak tesztelhetőnek kell lennie. Az alábbi ellenőrzőlista a szerződéses, működési és bizonyítékkövetelményeket egyetlen kontrollnézetbe rendezi.

Ezt az ellenőrzőlistát be kell építeni a beszerzésbe, a beléptetésbe, az időszakos felülvizsgálatba és az incidens-tesztelésbe. Ha bármely elem hiányzik, a szervezetnek ezt beszállítói kockázatként kell kezelnie, nem adminisztratív hiányosságként.

Az auditorok által elvárt hét bizonyítékterület

Az MDR-felügyelet auditkészségéhez a Clarysec hét területre rendezett MDR-bizonyítékállomány kialakítását javasolja. Ennek az állománynak az IBIR-en belül kell lennie, nem egy olyan beszerzési mappában, amelyet senki sem vizsgál felül.

Ez a táblázat megváltoztatja a szolgáltatóval folytatott párbeszédet. A „figyelnek minket?” kérdés helyett a szervezet azt kérdezi: „Negyedévente igazolni tudjuk-e, hogy az MDR-szolgáltatás továbbra is hatékony, megfelelő és összhangban van a kockázatvállalási hajlandóságunkkal?”

A naplózás híd az észlelés és a megfelelési bizonyítékok között

Megbízható naplózás nélkül az MDR kiszervezett találgatás. A szolgáltató észlelhet bizonyos fenyegetéseket, de a szervezet nem tudja igazolni a hatókört, az idővonalat, a gyökérokot vagy a hatást.

Az ISO/IEC 27002:2022 8.15 kontrollja a naplózásról szól. A Zenith Controls a naplózást olyan észlelő kontrollként sorolja be, amely támogatja a bizalmasságot, a sértetlenséget és a rendelkezésre állást, és összhangban van a Detect kiberbiztonsági koncepcióval és az információbiztonsági eseménykezelési képességgel. A naplózást közvetlenül összekapcsolja a monitorozási tevékenységekkel, az eseményértékeléssel, az incidensreagálással, a levont tanulságokkal, az emelt jogosultságú hozzáféréssel, az óraszinkronizálással, a hozzáférés-szabályozással, az adatvédelemmel, a bizonyítékgyűjtéssel, a sérülékenységkezeléssel és a fizikai biztonsági felügyelettel.

Ezért központi jelentőségű a naplózás a NIS2, a DORA és a GDPR Article 32 szerinti bizonyítékokhoz. A NIS2 Article 23 szerinti, jelentős incidensekre vonatkozó jelentéstétel 24 órán belüli korai figyelmeztetést ír elő a tudomásszerzéstől számítva, 72 órán belüli értesítést, valamint végső jelentést legkésőbb az értesítést követő egy hónapon belül. A DORA szerinti jelentős IKT-vonatkozású incidensjelentés besorolást, eszkalációt, kommunikációt, gyökérok-elemzést és végső jelentéstételt igényel. A GDPR szerinti elszámoltathatóság megköveteli, hogy a szervezetek igazolják, mi történt a személyes adatokkal, és megfelelőek voltak-e a biztonsági intézkedések.

A Clarysec Logging and Monitoring Policy - SME Naplózási és felügyeleti szabályzat - KKV egyszerű szerződéses kontrollt ad a külső szolgáltatókat használó kisebb szervezeteknek:

„A szerződéseknek elő kell írniuk, hogy a szolgáltatók legalább 12 hónapig őrizzék meg a naplókat, és kérésre biztosítsanak hozzáférést.”

Vállalati környezetek esetében a Logging and Monitoring Policy Naplózási és felügyeleti szabályzat hozzáadja a működési integrációs követelményt:

„Kérésre naplóadatokat kell biztosítani, vagy integrálódni kell a szervezet SIEM/naplóaggregáló platformjával.”

Ezek a kikötések egy visszatérő incidensreagálási problémát oldanak meg: kivizsgálás során az MDR-szolgáltató azt mondja, hogy az esemény régebbi, mint a kereshető megőrzési ablak, a naplók csak fizetős forenzikus exporttal érhetők el, vagy az ügyfél SIEM-rendszere nem tartalmazza a szolgáltatói gazdagítást és az elemzői műveleteket. Ha a naplóhozzáférést nem határozzák meg előre, az incidens-idővonal töredezetté válik.

Egy erős MDR-naplózási modellnek meg kell határoznia a kötelező naplóforrásokat, eseménytípusokat, megőrzési időket, sértetlenségvédelmet, hozzáférés-jóváhagyásokat, időszinkronizálást, exportformátumokat és a korrelációs szabályokat az ügyfél- és szolgáltatói platformok között. Ki kell terjednie a szolgáltatói műveletekre is, ideértve az észlelési szabályok módosításait, a végpont-elszigetelési parancsokat, az adminisztratív hozzáférést, az elemzői megjegyzéseket és a bizonyítékexportokat.

Az ISO támogató szabványai megerősítik ezt a megközelítést. Az ISO/IEC 27035-1:2023 és az ISO/IEC 27035-2:2023 összekapcsolja a naplózást az incidensészleléssel, a triázzsal és a központi elemzéssel. Az ISO/IEC 27701:2021 adatvédelmi szempontú naplózást ad hozzá a PII-kezelési tevékenységekhez. Az ISO/IEC 27017:2021 és az ISO/IEC 27018:2020 felhő- és felhőalapú PII-naplózási elvárásokat határoz meg, különösen akkor, ha a szolgáltatók nyilvános felhőkörnyezetben kezelnek ügyféladatokat. Az ISO/IEC 27005:2024 az elégtelen naplózást kockázatkezelési kérdésként keretezi, nem pusztán eszközhiányként.

Incidensreagálás: az MDR eszkalálhat, de a vezetésnek kell döntenie

Az MDR-szolgáltatók észlelnek és tanácsot adnak. Az elszámoltatható szervezet jelenti be az incidenseket, értékeli a szabályozói hatást, kommunikál a hatóságokkal, és dönt arról, szükséges-e személyesadat-sértési értesítés.

Ez a különbségtétel fontos, mert az MDR-súlyosság nem egyenlő automatikusan NIS2 szerinti jelentős incidenssel, DORA szerinti jelentős IKT-vonatkozású incidenssel vagy GDPR szerinti személyesadat-sértéssel. A szolgáltató „magas súlyosságúnak” címkézhet egy riasztást, de a szervezetnek kell eldöntenie, érintettek-e kritikus szolgáltatások, kompromittálódtak-e személyes adatok, kell-e ügyfeleket értesíteni, kell-e hatóságokat tájékoztatni, és a vezetésnek jóvá kell-e hagynia üzemeltetési hatással járó elszigetelési intézkedést.

A Clarysec Incident Response Policy - SME Incidenskezelési szabályzat - KKV egyértelműen fogalmaz:

„A harmadik feleknek az aláírt megállapodásoknak megfelelően kell eljárniuk, amelyeknek tartalmazniuk kell a személyesadat-sértés bejelentésére vonatkozó kikötéseket és az együttműködési reagálási kötelezettségeket.”

Ez az a kikötés, ahol a GDPR Article 32 szerinti bizonyíték találkozik az operatív incidensreagálással. Ha az MDR-szolgáltató személyes adatokat tartalmazó végpontról feltételezett adatkivitelt észlel, tudnia kell, milyen gyorsan és kit kell értesítenie, milyen bizonyítékot kell megőriznie, és hogyan kell támogatnia az adatkezelő értékelését.

A Clarysec Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint adja a tesztelési módszert. A Kontrollok működés közben fázisban, a 19. lépés alatt a Zenith Blueprint előírja a csapatoknak, hogy működés közben ellenőrizzék a naplózást és a felügyeletet:

„Válasszon ki egy közelmúltbeli incidenst vagy eseményt, és mutassa be, hogyan követte nyomon azt a naplók segítségével. Ha naplósértetlenségi funkciókat (pl. hash-ellenőrzést) használ, azt is dokumentálja. Erősítse meg, hogy a riasztás működik (pl. a sikertelen bejelentkezések vagy jogosultságkiterjesztések riasztást váltanak ki).”

Ugyanez a lépés az identitással és az emelt jogosultságú hozzáféréssel is foglalkozik:

„Emelt jogosultságú fiókok esetében ellenőrizze, hogy az MFA kikényszerített-e, az adminisztrátori szerepkörök elkülönítettek-e (admin_john típusú fiókok kizárólag adminisztrátori feladatokra), és létezik-e aktuális lista az emelt jogosultságú felhasználókról.”

MDR-környezetben az emelt jogosultságú felhasználók listájának a szolgáltatói fiókokat is tartalmaznia kell, nem csak a munkavállalókat. Ha az MDR-szolgáltató konzolhozzáféréssel, végpont-elszigetelési jogokkal, EDR-adminisztrációs jogokkal vagy érzékeny naplók olvasási hozzáférésével rendelkezik, ezek a fiókok a felülvizsgálat részét képezik.

A Zenith Blueprint 23. lépése ezután megadja az incidens- és beszállítói tesztelés szerkezetét:

„Válasszon ki egy közelmúltbeli eseményt, vagy végezzen asztali gyakorlatot a terv ellenőrzésére. Rögzítse és naplózza az összes döntést, szerepkört és kommunikációt (5.26), és frissítse a tervet a levont tanulságokkal (5.27). Erősítse meg, hogy rendelkezésre állnak eljárások a forenzikus bizonyítékok megőrzésére (5.28), ideértve a napló-pillanatképeket, a biztonsági mentéseket és az érintett rendszerek biztonságos elszigetelését.”

Egy reális asztali gyakorlatnak tartalmaznia kell az MDR-szolgáltatót is. Használjon olyan forgatókönyvet, mint kompromittálódott emelt jogosultságú fiók, végpont-elszigetelés, feltételezett postafiók-hozzáférés, lehetséges bérszámfejtési adatkitettség és munkaidőn kívüli riasztáseszkaláció. A tesztnek ellenőriznie kell, hogy az MDR-szolgáltató órája az észlelésnél, az ügyfél értesítésénél vagy az ügyfél visszaigazolásánál indul-e. Ez a különbség számít, amikor a szabályozói határidők a tudomásszerzéstől és a döntési pontoktól függenek.

Építsen egy riasztásalapú MDR-felügyeleti csomagot 90 perc alatt

A hiányosságok gyors feltárásának módja, ha kiválaszt egy közelmúltbeli magas súlyosságú MDR-riasztást, és egyoldalas bizonyítéknyomot készít. Ez a gyakorlati feladat jól működik auditok, igazgatósági felülvizsgálatok és szerződésmegújítások előtt.

1. Kezdje a riasztási jeggyel. Rögzítse az időbélyeget, az észlelési szabályt, az érintett eszközt, felhasználót, súlyosságot, az MDR-elemző megjegyzéseit és az eszkalációs útvonalat.
2. Keresse elő a szerződéses kikötést vagy SLA-t, amely megmutatja az adott súlyossághoz elvárt válaszidőt.
3. Keresse elő a naplóforrás-listát, amely igazolja, mely rendszerek táplálták a riasztást, például EDR, identitásszolgáltató, tűzfal, e-mail-biztonsági átjáró és felhőalapú auditnaplók.
4. Erősítse meg, hogy a naplókat a szabályzat szerint őrzik meg, és a korábbi esemény még visszakereshető.
5. Ellenőrizze, hogy az MDR-elemző hozzáfért-e bármely ügyfélkörnyezethez. Ha igen, rögzítse a névre szóló fiókot, az MFA-bizonyítékot, a munkamenet-naplókat és a jóváhagyást.
6. Dokumentálja az ügyféloldali döntést: esemény lezárva, incidens bejelentve, jogi értékelés elindítva, elszigetelés végrehajtva vagy kockázat elfogadva.
7. Ha személyes adatok érintettek lehetnek, rögzítse a GDPR szerinti szerepelemzést, az adatsértés-értékelés felelősét és azt, hogy aktiválódtak-e az adatfeldolgozói értesítési kötelezettségek.
8. Zárja le a levont tanulságokkal: finomhangolás, új észlelés, hozzáférésmódosítás, forgatókönyv-frissítés vagy beszállítói SLA-probléma.

Ez az egy riasztásra épülő nyomvonal azért erős, mert egyetlen bizonyítékláncban kapcsolja össze a szerződést, a naplózást, a hozzáférést, az incidensreagálást, az adatvédelmet és a vezetői felügyeletet. Ha egy közelmúltbeli riasztásra nem tudja elkészíteni, szabályozói nyomás alatt valószínűleg szintén nem fogja tudni.

A beszállítói felügyelet az a pont, ahol a legtöbb MDR-program meggyengül

Sok szervezet kellő gondossági vizsgálatot végez az MDR-szerződés aláírása előtt, majd megáll. Ez nem elegendő az ISO/IEC 27001:2022, a NIS2, a DORA vagy a GDPR szerint. Az MDR-szolgáltatások folyamatosan változnak: új észlelési szabályok, új elemzői csapatok, új al-adatfeldolgozók, új adatrégiók, új EDR-képességek, új integrációk, új fenyegetésintelligencia-hírcsatornák és új támogatási modellek jelennek meg.

Az ISO/IEC 27002:2022 5.22 kontrollja a beszállítói szolgáltatások monitorozásával, felülvizsgálatával és változáskezelésével foglalkozik. A Zenith Controls elmagyarázza, hogy az 5.22 a beszállítói kapcsolatokra és megállapodásokra épül, és biztosítja a szolgáltatásindítást követő folyamatos megfigyelést és irányítást. Kapcsolódik a zavarközbeni biztonsághoz, a sérülékenységkezeléshez, a megfeleléshez, a hozzáférés-szabályozáshoz és a biztonságos mérnöki munkához.

A DORA Articles 28 to 30 ezt különösen fontossá teszi a pénzügyi szervezetek számára. Folyamatos felügyeletet, az IKT-harmadikfél-megállapodások nyilvántartását, kritikussági megkülönböztetéseket, kellő gondosságot, audit- és vizsgálati jogokat, felmondási jogokat, kilépési stratégiákat, szolgáltatási szinteket, incidens-támogatást, a hatóságokkal való együttműködést, valamint kritikus vagy fontos funkciók esetében szolgáltatási célokat, vészhelyzeti tesztelést és adott esetben fenyegetésvezérelt penetrációs tesztelési együttműködést követelnek meg.

A Zenith Blueprint, Kontrollok működés közben fázis, 23. lépés, megadja a beszállítói életciklus szerkezetét:

„Állítsa össze az aktuális beszállítók és szolgáltatók teljes listáját (5.19), és sorolja be őket a rendszerekhez, adatokhoz vagy operatív kontrollhoz való hozzáférésük alapján.”

Majd így folytatja:

„Minden kritikus beszállító esetében azonosítsa, használnak-e olyan alvállalkozókat (al-adatfeldolgozókat), akik hozzáférhetnek az Ön adataihoz vagy rendszereihez.”

Gyakorlati MDR-szolgáltatás-felülvizsgálatot kritikus környezetek esetében negyedévente, alacsonyabb kockázatú környezetek esetében legalább évente kell tartani. A napirendnek tartalmaznia kell az SLA-megfelelést súlyosság szerint, az eszkalált riasztásokat, a valódi pozitív és téves pozitív eseteket, az elmaradt eszkalációkat, a naplóforrások állapotát, az emelt jogosultságú hozzáférési változásokat, az új integrációkat, az új régiókat, az alvállalkozókat, az al-adatfeldolgozókat, az észlelési szabályok változásait, az incidens-támogatási teljesítményt, a bizonyítékkéréseket, a nyitott kockázatokat, a helyesbítő intézkedéseket és a kilépési felkészültséget.

Ez nem mikromenedzsment. Ez az a bizonyossági kör, amely igazolja, hogy a szervezet aktívan irányít egy kritikus biztonsági beszállítót.

Keresztmegfelelési leképezés: egy MDR-kontrollkészlet, öt auditbeszélgetés

Az ISO/IEC 27001:2022 értéke abban áll, hogy koherens IBIR-ciklust ad a szervezeteknek több megfelelési beszélgetéshez. Ugyanaz az MDR-felügyeleti bizonyítékcsomag megfeleltethető a NIS2, DORA, GDPR, NIST CSF 2.0 és COBIT 2019 követelményeinek.

A NIST CSF 2.0 kommunikációhoz hasznos. GOVERN funkciója megköveteli, hogy a jogi, szabályozói, szerződéses és adatvédelmi kötelezettségeket megértsék és kezeljék, a szerepköröket és hatásköröket meghatározzák, a kiberbiztonsági kockázatot integrálják a vállalati kockázatkezelésbe, a beszállítói kockázatokat pedig kommunikálják és felügyeljék.

A COBIT 2019 vezetéshez és bizonyosságszerzéshez hasznos. A COBIT-orientált auditorok gyakran kevésbé egyetlen kontrollra, inkább arra fókuszálnak, hogy az irányítási célkitűzések, a szolgáltatáskezelés, a kockázattulajdonosi felelősség és a teljesítményfelügyelet rendszerként működik-e.

Hogyan tesztelik az auditorok az MDR-szolgáltatói felügyeletet

A különböző auditorok eltérő nézőpontokat alkalmaznak, de mind bizonyítékot akarnak arra, hogy a szervezet ellenőrzés alatt tartja a kapcsolatot.

Egy ISO/IEC 27001:2022 auditor az alkalmazási területtel, az érdekelt felekkel, a kockázatértékeléssel, az alkalmazhatósági nyilatkozattal, a kockázatkezelési tervvel és a működési bizonyítékokkal kezdi. Ha az MDR az alkalmazási terület része, az auditor elvárja, hogy a külső fél által biztosított folyamatokat az IBIR keretében ellenőrzés alatt tartsák. Mintavétellel vizsgálhatja a beszállítói kapcsolatokat, a beszállítói megállapodásokat, a beszállítói szolgáltatások felügyeletét, a naplózást, a monitorozást, az incidensreagálást, a bizonyítékkezelést és a hozzáférés-szabályozást.

Egy DORA felügyeleti hatóság az operatív rezilienciára és a rendszerszintű kockázatra fókuszál. Vizsgálhatja a kritikussági értékelést, az IKT-szolgáltatási nyilvántartást, a koncentrációs kockázat elemzését, a kilépési stratégiát, az incidensbesorolást, az auditálási jogokat és annak bizonyítékát, hogy az MDR-szolgáltató támogatni tudja a szabályozói jelentéstételt.

Egy GDPR-auditor vagy adatvédelmi felülvizsgáló az adatkezelő-adatfeldolgozó irányításra fókuszál. Kérni fogja az adatfeldolgozási megállapodást, az adatfeldolgozói kellő gondosságot, az al-adatfeldolgozói kontrollokat, a személyes adatokat tartalmazó naplókra vonatkozó védelmi intézkedéseket, a megőrzési kontrollokat, az adatsértés-értékelési bejegyzéseket és az Article 32 alátámasztására szolgáló bizonyítékokat.

Egy COBIT- vagy ISACA-auditor az irányítási bizonyítékokat vizsgálja: a beszállítói kockázatgazdai felelősséget, a beszerzési munkafolyamatot, a szolgáltatás-felülvizsgálati jegyzőkönyveket, az SLA-problémák nyomon követését, a helyesbítő intézkedéseket, a bizonyítékok minőségét és azt, hogy a vezetés kap-e érdemi mutatókat.

A leginkább feltáró auditkérés egyszerű: „Mutasson be egy MDR-riasztást az észleléstől a lezárásig.” Ha be tudja mutatni a szerződéses elvárást, a naplóforrást, a riasztást, az eszkalációt, a döntést, a bizonyítékmegőrzést, az adatvédelmi értékelést, a helyesbítő intézkedést és a vezetői jelentéstételt, az MDR-felügyelet érett. Ha csak egy beszállítói jegyet tud megmutatni, van monitorozás, de gyenge az irányítás.

Vezetői jelentéstétel: az igazgatóságnak nincs szüksége csomagrögzítésekre

A NIS2 és a DORA egyaránt vezető testületi szintre helyezi a felelősséget. Az igazgatóságoknak és felsővezetőknek nincs szükségük nyers telemetriára. Kockázati szempontból releváns MDR-felügyeleti mutatókra van szükségük.

Egy hasznos negyedéves MDR-irányítópult tartalmazza:

• A bekapcsolt kritikus naplóforrásokat az elvártakhoz képest.
• Az MDR által lefedett kritikus eszközök arányát.
• A magas súlyosságú riasztásokat kategória és üzleti szolgáltatás szerint.
• Az észleléstől az ügyfél értesítéséig eltelt átlagos időt.
• Az ügyfél visszaigazolásától a döntésig eltelt átlagos időt.
• Az SLA-sértéseket és a lezáratlan szolgáltatói intézkedéseket.
• Az emelt jogosultságú szolgáltatói fiókok felülvizsgálati állapotát.
• Az alvállalkozói vagy al-adatfeldolgozói változásokat.
• A jogi, szabályozói vagy ügyfélértesítési értékelést igénylő incidenseket.
• A megvalósított, levont tanulságokat.

Ennek az irányítópultnak táplálnia kell az IBIR vezetőségi felülvizsgálatát, a kockázatkezelési frissítéseket és a beszállítói felülvizsgálatot. Az ISO/IEC 27001:2022 szerint a vezetésnek biztosítania kell, hogy az IBIR összhangban legyen a stratégiai iránnyal, rendelkezésre álljanak az erőforrások, a felelősségek kiosztásra kerüljenek, a kommunikáció működjön, és folyamatos fejlesztés történjen. Az MDR-mutatók gyakorlati módon mutatják meg, hogy a kiszervezett biztonsági üzemeltetést a vezetés irányítja, nem pedig eszközadminisztrátorokra hagyják.

Gyakori MDR-felügyeleti buktatók, amelyeket a 2026-os auditok előtt javítani kell

A leggyakoribb hiányosságok hétköznapi irányítási hibák.

Először: a szervezetek megfeledkeznek arról, hogy az MDR-szolgáltatók személyes adatokat kezelhetnek. A biztonsági naplókat néha „technikai adatként” kezelik, pedig tartalmazhatnak személyes adatokat, alkalmanként érzékeny tartalmat is. A GDPR szerinti szerepelemzést és adatfeldolgozói kikötéseket a beléptetés előtt kell elkészíteni, nem adatsértés során.

Másodszor: a naplómegőrzést feltételezik, nem szerződésben rögzítik. Ha szabályozói, forenzikus vagy ügyfélkötelezettségek hónapokig megkövetelik a bizonyítékok rendelkezésre állását, az MDR- és SIEM-megőrzési modellnek ezt támogatnia kell. A KKV-szabályzat 12 hónapos szolgáltatói naplómegőrzési követelménye sok környezet számára gyakorlati alapkövetelmény.

Harmadszor: a harmadik fél hozzáférése túl széles. A szolgáltatói fiókoknak névre szólónak, MFA-val védettnek, felügyeltnek, felülvizsgáltnak és lehetőség szerint időkorlátosnak kell lenniük. A megosztott fiókok és a felügyelet nélküli adminisztratív munkamenetek audit- és incidensreagálási kockázatot teremtenek.

Negyedszer: az incidensküszöbök nem egyértelműek. Az MDR-súlyosság nem egyenlő automatikusan jogi incidenssel, DORA szerinti jelentős IKT-vonatkozású incidenssel, NIS2 szerinti jelentős incidenssel vagy GDPR szerinti személyesadat-sértéssel. A forgatókönyvnek meg kell határoznia, ki hozza meg az egyes döntéseket.

Ötödször: az alvállalkozók láthatatlanok. Ha az MDR-szolgáltató elemzési platformot, támogatási régiót vagy alsóbb szintű adatfeldolgozót vált, az ügyfél kockázati képe megváltozik. Az előzetes írásbeli hozzájárulás és az időszakos felülvizsgálat elengedhetetlen.

Hatodszor: a szolgáltatás-felülvizsgálatok csak a jegymennyiségre koncentrálnak. Az érett felülvizsgálatok vizsgálják az elmaradt riasztásokat, a finomhangolási változásokat, a naplóforrások állapotát, a bizonyítékok visszakereshetőségét, a szolgáltatói hozzáférést, az incidens-együttműködést és a szerződéses kötelezettségeket.

Következő lépések: tegye MDR-szolgáltatóját auditkész állapotba a Clarysec segítségével

Ha az MDR-szolgáltatója már élesben működik, ne várja meg, amíg egy szabályozó, ügyfélauditor vagy incidens feltárja, hogy a bizonyítékai hiányosak. Kezdjen egy közelmúltbeli riasztással, és építse fel a nyomvonalat. Ezután sorolja be a szolgáltatót, vizsgálja felül a szerződést, ellenőrizze a naplózást, tesztelje az eszkalációt, erősítse meg az adatfeldolgozói kikötéseket, vizsgálja felül a hozzáférést, és ütemezze a beszállítói felügyeletet.

A Clarysec segíthet ennek gyors operatív megvalósításában az alábbiakkal:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint a szakaszos bevezetéshez, ideértve a 19. lépést a naplózás, felügyelet és hozzáférés ellenőrzéséhez, valamint a 23. lépést a beszállítói és incidenskezelési kontrollokhoz.
• Zenith Controls: The Cross-Compliance Guide Zenith Controls az ISO/IEC 27002:2022 5.19, 5.22 és 8.15 kontrolljainak NIS2, DORA, GDPR, NIST és COBIT audit elvárásokhoz való leképezéséhez.
• Clarysec szabályzatsablonok, ideértve az Incidenskezelési szabályzatot, a Harmadik fél és beszállítói biztonsági szabályzatot, a Naplózási és felügyeleti szabályzatot, az Incidenskezelési szabályzat - KKV, a Harmadik fél és beszállítói biztonsági szabályzat - KKV, a Naplózási és felügyeleti szabályzat - KKV és az Adatvédelmi és magánszféra-védelmi szabályzat - KKV sablonokat.

Az MDR az egyik legértékesebb biztonsági beruházás, amelyet egy szervezet megtehet. 2026-ban ezt az értéket irányítással, bizonyítékokkal és elszámoltatható felügyelettel kell igazolni. Ha gyakorlati MDR-felügyeleti csomagot szeretne ISO/IEC 27001:2022, NIS2, DORA és GDPR Article 32 megfeleltetéssel, a Clarysec segít felépíteni azt, mielőtt a következő riasztásból a következő auditmegállapítás lesz.