Dohľad nad poskytovateľom MDR pre NIS2, DORA a GDPR

V pondelok o 02:13 ráno otvorí poskytovateľ MDR upozornenie s vysokou závažnosťou: nemožné cestovanie, podozrivé pravidlá poštovej schránky a privilegovaný účet použitý z nespravovaného koncového bodu. Analytik SOC eskaluje udalosť cez tiketovací portál. Váš IT manažér spí. CFO dostane phishingové varovanie od bankového kontaktu ešte predtým, ako sa aktivuje interný incidentný kanál. O 07:30 čelí CISO trom nepríjemným otázkam.

Kto mal právomoc vyhlásiť incident?

Vieme preukázať, že poskytovateľ MDR mal k dispozícii správne logy, uchovával ich dostatočne dlho a zabezpečil dôkazy?

Ak došlo k prístupu k osobným údajom, dokáže právne oddelenie splniť lehoty na posúdenie porušenia ochrany osobných údajov podľa GDPR, zatiaľ čo prevádzka pripravuje oznámenie podľa NIS2 alebo DORA?

O mesiac neskôr si externý audítor vyžiada tie isté dôkazy, len iným tónom. PDF správa poskytovateľa MDR je užitočná, ale nestačí. Audítor požaduje surové údaje upozornení, úplné súbory logov, eskalačnú stopu, interný záznam rozhodnutí, záznam o preskúmaní dodávateľa a dôkaz, že organizácia dokázala nezávisle overiť, čo sa stalo.

Toto je problém dohľadu nad poskytovateľom MDR v roku 2026. Organizácie outsourcujú detekciu a reakciu, pretože interná kapacita SOC je drahá, nábor je náročný a aktivita hrozieb je nepretržitá. Outsourcovaná detekcia však neznamená outsourcovanú zodpovednosť. Podľa NIS2 zostávajú riadiace orgány zodpovedné za schvaľovanie opatrení riadenia kybernetických rizík a dohľad nad nimi. Podľa DORA zostávajú finančné subjekty plne zodpovedné za riziká externých poskytovateľov IKT služieb vrátane kritických IKT služieb, podpory pri incidentoch, práv na audit, subdodávok a ukončenia spolupráce. Podľa GDPR musia prevádzkovatelia preukázať primeranú bezpečnosť spracúvania, najmä ak sprostredkovatelia spracúvajú telemetriu, údaje z koncových bodov, identifikátory používateľov, IP adresy, obsah e-mailov, logy alebo forenzné obrazy.

Praktická medzera zriedka spočíva iba v zmluve MDR. Spočíva v dôkazovom reťazci medzi zmluvou a živou službou: smerovanie upozornení, privilegovaný prístup, uchovávanie logov, prahové hodnoty eskalácie, dôkazy o incidente, transparentnosť subdodávateľov, ustanovenia pre sprostredkovateľov, preskúmania služieb, stolové cvičenia a reportovanie manažmentu.

Obhájiteľný program dohľadu nad poskytovateľom MDR potrebuje jeden prevádzkový model, ktorý obstojí vo viacerých auditných diskusiách. ISO/IEC 27001:2022 poskytuje túto kostru.

Dohľad nad MDR sa začína zodpovednosťou, nie konzolou SOC

Častou chybou je považovať onboarding MDR za technický projekt: nasadiť agentov EDR, odosielať logy identít, nakonfigurovať upozornenia, dohodnúť kanál v Teams alebo Slack a spustiť službu do produkcie. To môže zlepšiť detekciu, ale nepreukazuje to správu a riadenie.

NIS2 túto otázku pomenúva explicitne. Základné a dôležité subjekty musia zaviesť primerané a proporcionálne technické, prevádzkové a organizačné opatrenia riadenia kybernetických rizík. Article 21 zahŕňa analýzu rizík, riešenie incidentov, kontinuitu činností, bezpečnosť dodávateľského reťazca, kybernetickú hygienu, riadenie prístupu, správu aktív, kryptografiu a viacfaktorovú autentifikáciu. Article 20 posúva túto požiadavku na úroveň zodpovednosti riadiaceho orgánu a vyžaduje schválenie týchto opatrení a dohľad nad nimi.

Poskytovatelia MDR často pokrývajú viacero oblastí NIS2 Article 21 naraz:

• Riešenie incidentov, pretože poskytovateľ vykonáva triáž, eskaluje a môže odporúčať zamedzenie šírenia.
• Bezpečnosť dodávateľského reťazca, pretože poskytovateľ je priamym poskytovateľom služby s dopadom na prevádzkovú bezpečnosť.
• Riadenie prístupu, pretože poskytovateľ môže pristupovať ku konzolám, logom, nástrojom koncových bodov alebo cloudovým tenantom.
• Logovanie a monitorovanie, pretože detekcia závisí od pokrytia logmi, uchovávania a korelácie.
• Kybernetickú hygienu, pretože zistenia MDR často odhaľujú slabiny v záplatovaní, identitách alebo konfigurácii.
• Kontinuitu činností, pretože oneskorená reakcia môže narušiť kritické služby.

Pre finančné subjekty DORA sprísňuje prevádzkový model. DORA sa uplatňuje od 17. januára 2025 a vyžaduje riadenie rizík IKT, nahlasovanie incidentov, testovanie odolnosti, zdieľanie informácií a riadenie rizík externých poskytovateľov IKT služieb. Zároveň objasňuje, že pre finančné subjekty identifikované aj podľa NIS2 funguje DORA ako sektorovo špecifický právny akt Únie pre prekrývajúce sa povinnosti kybernetickej bezpečnosti. Regulovaná banka, platobná inštitúcia, investičná spoločnosť, poisťovňa alebo poskytovateľ služieb kryptoaktív nemôže jednoducho povedať: „To rieši náš poskytovateľ MDR.“ DORA očakáva, že subjekt bude klasifikovať incidenty IKT, riadiť a monitorovať externých poskytovateľov IKT služieb, viesť register zmluvných dohôd o IKT službách, definovať zmluvné práva, testovať odolnosť, vykonávať analýzu koreňovej príčiny a postupne hlásiť závažné incidenty súvisiace s IKT.

GDPR pridáva iný pohľad. Ak telemetria MDR obsahuje identifikátory používateľov, IP adresy, metadáta e-mailov, autentifikačné záznamy, artefakty koncových bodov alebo súbory obsahujúce osobné údaje, uplatňujú sa zásady bezpečnosti a zodpovednosti podľa GDPR. Article 5 zahŕňa integritu, dôvernosť a zodpovednosť. Article 32 o bezpečnosti spracúvania sa stáva praktickou otázkou dôkazov: boli logy chránené, bol prístup obmedzený, bolo podľa potreby použité šifrovanie, boli sprostredkovatelia riadení a vie organizácia preukázať, čo sa stalo?

Posolstvo je vo všetkých troch režimoch konzistentné: prácu môžete delegovať, zodpovednosť nie.

ISO/IEC 27001:2022 mení MDR na auditovateľný proces

Dobre zavedený ISMS založený na ISO/IEC 27001:2022 mení dohľad nad poskytovateľom MDR zo sľubu v oblasti riadenia dodávateľov na prevádzkový model založený na dôkazoch. Kapitola 8.1 je obzvlášť dôležitá, pretože vyžaduje, aby organizácie riadili externe poskytované procesy, produkty a služby relevantné pre ISMS. MDR je presne takýto prípad: externe poskytovaný proces, ktorý môže ovplyvniť reakciu na incidenty, súkromie, odolnosť, regulačné oznamovanie a kontinuitu činností.

Najdôležitejšie oblasti prílohy A ISO/IEC 27001:2022 pre dohľad nad MDR zahŕňajú vzťahy s dodávateľmi, bezpečnostné požiadavky v dohodách s dodávateľmi, riadenie rizík dodávateľského reťazca IKT, monitorovanie služieb dodávateľov, riadenie incidentov, nakladanie s dôkazmi, logovanie, monitorovanie, riadenie prístupu, privilegovaný prístup, kryptografiu a pripravenosť kontinuity činností.

Clarysec Zenith Controls: The Cross-Compliance Guide Zenith Controls je referenčným materiálom pre túto prácu naprieč rámcami súladu. Mapuje kontroly ISO/IEC 27002:2022 na ďalšie požiadavky, súvisiace kontroly, auditné očakávania a implementačné dôkazy. Pre dohľad nad MDR sú kľúčové tri kontroly ISO/IEC 27002:2022: 5.19 pre vzťahy s dodávateľmi, 5.22 pre monitorovanie služieb dodávateľov a riadenie zmien a 8.15 pre logovanie. Podporujú ich 5.20 dohody s dodávateľmi, 5.21 bezpečnosť dodávateľského reťazca IKT, 5.24 až 5.28 riadenie incidentov a nakladanie s dôkazmi, 5.34 súkromie a PII, 5.36 súlad, 8.16 monitorovacie činnosti, 8.17 synchronizácia systémového času, 8.18 používanie privilegovaných obslužných programov a 8.8 riadenie technických zraniteľností.

Je to dôležité preto, že zlyhanie auditu MDR zriedka znie „MDR neexistuje“. Zvyčajne znamená niektorú z týchto situácií:

• Poskytovateľ MDR nebol klasifikovaný ako kritický.
• Zmluvné ustanovenia nezahŕňali oznamovanie incidentov, prístup k dôkazom alebo práva na audit.
• Logy sa neuchovávali dostatočne dlho na vyšetrenie nahlásenej udalosti.
• Prístup poskytovateľa bol zdieľaný, trvalý alebo nemonitorovaný.
• Zákazník nepreskúmaval výkonnosť MDR voči SLA.
• Subdodávatelia alebo ďalší sprostredkovatelia neboli schválení.
• Oznamovacie povinnosti pri porušení ochrany osobných údajov neboli zosúladené s pracovnými tokmi incidentov.
• Dôkazy neboli zabezpečené spôsobom použiteľným pre forenznú analýzu.
• Manažment nemal metriky ukazujúce, či služba MDR znížila riziko.

Zenith Controls jasne opisuje vzťah medzi očakávaniami voči dodávateľom a dohodami:

„5.19 stanovuje bezpečnostné očakávania týkajúce sa toho, ako majú dodávatelia nakladať s informáciami organizácie. 5.20 tieto očakávania formalizuje tým, že zabezpečuje, aby zmluvy alebo dohody výslovne obsahovali bezpečnostné ustanovenia, napríklad požiadavky na dôvernosť, dodržiavanie bezpečnostných politík a postupy oznamovania incidentov. Bez 5.20 nemusia byť požiadavky identifikované v 5.19 právne vymáhateľné.“

Pre MDR je táto veta lekciou zo správy a riadenia. Ak zmluva nevyžaduje, aby poskytovateľ uchovával logy, poskytoval dôkazy, spolupracoval pri incidentoch, obmedzoval subdodávky, podporoval audity a dodržiaval eskalačné lehoty, služba SOC môže byť prevádzkovo užitočná, ale z pohľadu auditu slabá.

Čo musí zmluva MDR preukázať pred prvým upozornením

Dobrá zmluva MDR nie je iba komerčný objednávkový formulár. Je to kontrolný dokument. DORA Articles 28 až 30 vyžadujú riadenie rizík externých poskytovateľov IKT služieb počas celého životného cyklu vrátane registrov zmlúv IKT, klasifikácie kritickosti, predzmluvnej due diligence, práv na audit a kontrolu, práv na ukončenie, exit stratégií, jasných opisov služieb, úrovní služieb, miest poskytovania služby a spracúvania údajov, záväzkov ochrany údajov, pomoci pri incidentoch a spolupráce s orgánmi. NIS2 Article 21 vyžaduje bezpečnosť dodávateľského reťazca pre priamych dodávateľov a poskytovateľov služieb. GDPR vyžaduje roly prevádzkovateľa a sprostredkovateľa, záruky sprostredkovateľa, ustanovenia o ochrane údajov a dôkazy o bezpečnosti spracúvania.

Knižnica politík Clarysec premieňa tieto povinnosti na praktické zmluvné a prevádzkové požiadavky. V Enterprise Incident Response Policy Politika reakcie na incidenty sa MDR výslovne považuje za riadenú schopnosť tretej strany pri incidentoch:

„Integrácia so službami tretích strán vrátane Managed Detection and Response (MDR), Security Incident and Event Management (SIEM) a poskytovateľov forenznej analýzy musí byť riadená jasne definovanými dohodami o úrovni služieb (SLA) a ustanoveniami o mlčanlivosti.“

Toto ustanovenie je dôležité, pretože poskytovatelia MDR často získajú vysoko citlivé informácie skôr, ako organizácia vie, či incident podlieha oznamovaniu. Telemetria môže obsahovať používateľské mená, cesty k súborom, predmety e-mailov, interné názvy hostiteľov, IP adresy, sieťové diagramy a indikátory kompromitácie. Ustanovenia o mlčanlivosti chránia organizáciu počas vyšetrovania a podporujú zodpovednosť podľa GDPR.

Enterprise Third party and supplier security policy Politika bezpečnosti tretích strán a dodávateľov pridáva dve ustanovenia, ktoré audítori očakávajú pri preskúmavaní dohľadu nad MDR:

„Práva na audit, kontrolu a vyžiadanie bezpečnostných dôkazov“

a:

„Použitie subdodávateľov podliehajúce predchádzajúcemu písomnému súhlasu“

Pre MSP sa rovnaký princíp správy a riadenia zjednodušuje, ale neodstraňuje. Third-Party and Supplier Security Policy - SME Politika bezpečnosti tretích strán a dodávateľov - MSP vyžaduje zásadu minimálnych oprávnení:

„Dodávateľom musí byť udelený prístup iba k minimálnym systémom a údajom potrebným na vykonanie ich funkcie.“

Vyžaduje tiež:

„Obmedzenia ďalšieho subdodávateľského zabezpečenia bez schválenia“

Tieto ustanovenia sú pre MDR obzvlášť relevantné. Mnohí poskytovatelia využívajú viacúrovňové tímy SOC, dodávateľov platforiem, partnerov pre spravodajstvo o hrozbách, cloudové analytické služby alebo regionálny podporný personál. Ak následné strany môžu pristupovať k logom zákazníka alebo osobným údajom, zákazník potrebuje mechanizmy transparentnosti a schvaľovania. V terminológii DORA ide o súčasť dohľadu nad subdodávkami a rizikom koncentrácie. V terminológii GDPR ide o správu a riadenie ďalších sprostredkovateľov. V terminológii NIS2 ide o riadenie rizík dodávateľského reťazca.

Základný kontrolný zoznam dohľadu nad MDR

Obhájiteľný vzťah s poskytovateľom MDR musí byť testovateľný. Nasledujúci kontrolný zoznam spája zmluvné, prevádzkové a dôkazové požiadavky do jedného pohľadu na kontroly.

Tento kontrolný zoznam má byť začlenený do obstarávania, onboardingu, pravidelného preskúmania a testovania incidentov. Ak niektorá položka chýba, organizácia ju má považovať za dodávateľské riziko, nie za administratívny nedostatok.

Sedem dôkazových oblastí, ktoré audítori očakávajú

Aby bol dohľad nad MDR pripravený na audit, Clarysec odporúča vytvoriť dôkazový súbor MDR usporiadaný do siedmich oblastí. Tento súbor má byť súčasťou ISMS, nie priečinka obstarávania, ktorý nikto nepreskúmava.

Táto tabuľka mení diskusiu s poskytovateľom. Namiesto otázky „Monitorujete nás?“ sa organizácia pýta: „Vieme každý štvrťrok preukázať, že služba MDR zostáva účinná, v súlade a zosúladená s naším apetítom na riziko?“

Logovanie je mostom medzi detekciou a dôkazmi súladu

MDR bez spoľahlivého logovania je outsourcovaný odhad. Poskytovateľ môže zistiť niektoré hrozby, ale organizácia nedokáže preukázať rozsah, časovú os, koreňovú príčinu ani dopad.

Kontrola ISO/IEC 27002:2022 8.15 sa týka logovania. Zenith Controls klasifikuje logovanie ako detekčné opatrenie podporujúce dôvernosť, integritu a dostupnosť, zosúladené s konceptom kybernetickej bezpečnosti Detect a schopnosťou riadenia udalostí informačnej bezpečnosti. Priamo prepája logovanie s monitorovacími činnosťami, hodnotením udalostí, reakciou na incidenty, získanými poznatkami, privilegovaným prístupom, synchronizáciou systémového času, riadením prístupu, súkromím, zberom dôkazov, riadením zraniteľností a monitorovaním fyzickej bezpečnosti.

Preto je logovanie kľúčové pre dôkazy podľa NIS2, DORA a GDPR Article 32. Oznamovanie významných incidentov podľa NIS2 Article 23 vyžaduje včasné varovanie do 24 hodín od získania vedomosti, oznámenie do 72 hodín a záverečnú správu najneskôr jeden mesiac po oznámení. Oznamovanie závažných incidentov súvisiacich s IKT podľa DORA vyžaduje klasifikáciu, eskaláciu, komunikáciu, analýzu koreňovej príčiny a záverečné hlásenie. Zodpovednosť podľa GDPR vyžaduje, aby organizácie preukázali, čo sa stalo s osobnými údajmi a či boli bezpečnostné opatrenia primerané.

Clarysec Logging and Monitoring Policy - SME Politika logovania a monitorovania - MSP poskytuje jednoduchú zmluvnú kontrolu pre menšie organizácie využívajúce externých poskytovateľov:

„Zmluvy musia vyžadovať, aby poskytovatelia uchovávali logy najmenej 12 mesiacov a poskytli k nim prístup na požiadanie“

Pre podnikové prostredia Logging and Monitoring Policy Politika logovania a monitorovania dopĺňa požiadavku prevádzkovej integrácie:

„Musia poskytnúť logové údaje na požiadanie alebo sa integrovať s platformou SIEM/agregácie logov organizácie.“

Tieto ustanovenia riešia opakujúci sa problém reakcie na incidenty: počas vyšetrovania poskytovateľ MDR uvedie, že udalosť je staršia než prehľadateľné retenčné okno, logy sú dostupné iba cez platený forenzný export alebo SIEM zákazníka neobsahuje obohatenia poskytovateľa a kroky analytika. Ak prístup k logom nie je definovaný vopred, časová os incidentu sa fragmentuje.

Silný model logovania MDR má definovať povinné zdroje logov, typy udalostí, lehoty uchovávania, ochranu integrity, schvaľovanie prístupu, synchronizáciu času, exportné formáty a korelačné pravidlá medzi platformami zákazníka a poskytovateľa. Má pokrývať aj kroky poskytovateľa vrátane zmien detekčných pravidiel, príkazov na izoláciu koncových bodov, administrátorského prístupu, poznámok analytikov a exportov dôkazov.

Podporné normy ISO tento prístup posilňujú. ISO/IEC 27035-1:2023 a ISO/IEC 27035-2:2023 prepájajú logovanie s detekciou incidentov, triážou a centralizovanou analýzou. ISO/IEC 27701:2021 dopĺňa logovanie spracovateľských činností PII špecifické pre súkromie. ISO/IEC 27017:2021 a ISO/IEC 27018:2020 dopĺňajú očakávania logovania pre cloud a cloudové PII, najmä keď poskytovatelia spracúvajú údaje zákazníkov vo verejných cloudových prostrediach. ISO/IEC 27005:2024 rámcuje nedostatočné logovanie ako otázku ošetrenia rizík, nie iba medzeru v nástrojoch.

Reakcia na incidenty: MDR môže eskalovať, ale rozhodovať musí manažment

Poskytovatelia MDR detegujú a radia. Zodpovedná organizácia vyhlasuje incidenty, posudzuje regulačný dopad, komunikuje s orgánmi a rozhoduje, či sa vyžaduje oznámenie porušenia ochrany osobných údajov.

Toto rozlíšenie je dôležité, pretože závažnosť MDR automaticky neznamená významný incident podľa NIS2, závažný incident súvisiaci s IKT podľa DORA ani porušenie ochrany osobných údajov podľa GDPR. Poskytovateľ môže označiť upozornenie ako „vysoká závažnosť“, ale organizácia musí rozhodnúť, či boli ovplyvnené kritické služby, či boli kompromitované osobné údaje, či musia byť informovaní zákazníci, či musia byť informované regulačné orgány a či musí manažment schváliť zamedzujúce opatrenie s prevádzkovým dopadom.

Clarysec Incident Response Policy - SME Politika reakcie na incidenty - MSP je priama:

„Tretie strany musia konať v súlade s podpísanými dohodami, ktoré musia obsahovať ustanovenia o oznamovaní porušení ochrany osobných údajov a povinnosti spolupráce pri reakcii.“

Toto ustanovenie je miestom, kde sa dôkazy podľa GDPR Article 32 stretávajú s prevádzkovou reakciou na incidenty. Ak poskytovateľ MDR spozoruje podozrenie na exfiltráciu údajov z koncového bodu obsahujúceho osobné údaje, musí vedieť, ako rýchlo oznámiť, komu oznámiť, aké dôkazy zachovať a ako podporiť posúdenie prevádzkovateľa.

Clarysec Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint poskytuje testovaciu metódu. Vo fáze Controls in Action, Step 19, Zenith Blueprint usmerňuje tímy, aby prevádzkovo overili logovanie a monitorovanie:

„Vyberte nedávny incident alebo udalosť a ukážte, ako ste ju vystopovali pomocou logov. Ak sa používajú funkcie integrity logov (napr. overenie hashu), zdokumentujte aj to. Potvrďte, že upozorňovanie je funkčné (napr. neúspešné prihlásenia alebo eskalácie oprávnení spúšťajú upozornenia).“

Ten istý krok sa venuje identite a privilegovanému prístupu:

„Pri privilegovaných účtoch overte, že MFA je vynútená, administrátorské roly sú oddelené (účty typu admin_john sa používajú iba na administrátorské úlohy) a existuje aktuálny zoznam privilegovaných používateľov.“

V kontexte MDR musí zoznam privilegovaných používateľov zahŕňať účty poskytovateľa, nielen zamestnancov. Ak má poskytovateľ MDR prístup ku konzole, práva na izoláciu koncových bodov, administrátorské práva EDR alebo prístup iba na čítanie k citlivým logom, tieto účty patria do preskúmania.

Step 23 dokumentu Zenith Blueprint následne poskytuje štruktúru testovania incidentov a dodávateľov:

„Vyberte nedávnu udalosť alebo vykonajte stolové cvičenie na overenie plánu. Zachyťte a zalogujte všetky rozhodnutia, roly a komunikáciu (5.26) a aktualizujte plán o získané poznatky (5.27). Potvrďte, že sú zavedené postupy na zachovanie forenzných dôkazov (5.28) vrátane snapshotov logov, záloh a bezpečnej izolácie ovplyvnených systémov.“

Realistické stolové cvičenie má zahŕňať poskytovateľa MDR. Použite scenár, ako je kompromitovaný privilegovaný účet, izolácia koncového bodu, podozrenie na prístup do poštovej schránky, možné sprístupnenie mzdových údajov a eskalácia upozornenia mimo pracovného času. Test má overiť, či sa hodiny poskytovateľa MDR spúšťajú pri detekcii, oznámení zákazníkovi alebo potvrdení zo strany zákazníka. Toto rozlíšenie je dôležité, keď regulačné lehoty závisia od okamihu vedomosti a rozhodovacích bodov.

Vybudujte balík dohľadu nad MDR pre jedno upozornenie za 90 minút

Rýchly spôsob, ako odhaliť medzery, je vybrať jedno nedávne upozornenie MDR s vysokou závažnosťou a vytvoriť jednostránkovú dôkazovú stopu. Toto praktické cvičenie funguje dobre pred auditmi, preskúmaniami predstavenstvom a obnovami zmlúv.

1. Začnite tiketom upozornenia. Zachyťte časovú pečiatku, detekčné pravidlo, ovplyvnené aktívum, používateľa, závažnosť, poznámky analytika MDR a eskalačný postup.
2. Vyhľadajte zmluvné ustanovenie alebo SLA, ktoré preukazuje očakávaný čas reakcie pre danú závažnosť.
3. Získajte zoznam zdrojov logov, ktorý preukazuje, ktoré systémy napájali upozornenie, napríklad EDR, poskytovateľ identít, firewall, e-mailová bezpečnostná brána a cloudové auditné logy.
4. Potvrďte, že logy sa uchovávajú podľa politiky a že historickú udalosť možno stále vyhľadať.
5. Overte, či analytik MDR pristupoval do akéhokoľvek prostredia zákazníka. Ak áno, zachyťte pomenovaný účet, dôkazy MFA, logy relácie a schválenie.
6. Zdokumentujte rozhodnutie na strane zákazníka: udalosť uzavretá, incident vyhlásený, spustené právne posúdenie, vykonané zamedzenie šírenia alebo akceptované riziko.
7. Ak môžu byť dotknuté osobné údaje, zaznamenajte analýzu rolí podľa GDPR, vlastníka posúdenia porušenia ochrany osobných údajov a či boli aktivované oznamovacie povinnosti sprostredkovateľa.
8. Uzavrite získanými poznatkami: ladenie, nová detekcia, zmena prístupu, aktualizácia playbooku alebo problém SLA dodávateľa.

Táto stopa jedného upozornenia je silná, pretože prepája zmluvu, logovanie, prístup, reakciu na incidenty, súkromie a dohľad manažmentu do jedného dôkazového reťazca. Ak ju neviete vytvoriť pre nedávne upozornenie, pravdepodobne ju neviete vytvoriť ani pod regulačným tlakom.

Monitorovanie dodávateľov je miesto, kde väčšina programov MDR slabne

Mnohé organizácie vykonajú due diligence pred podpisom zmluvy MDR a potom skončia. To nestačí pre ISO/IEC 27001:2022, NIS2, DORA ani GDPR. Služby MDR sa neustále menia: nové detekčné pravidlá, nové tímy analytikov, noví ďalší sprostredkovatelia, nové dátové regióny, nové schopnosti EDR, nové integrácie, nové zdroje spravodajstva o hrozbách a nové modely podpory.

Kontrola ISO/IEC 27002:2022 5.22 sa venuje monitorovaniu, preskúmaniu a riadeniu zmien služieb dodávateľov. Zenith Controls vysvetľuje, že 5.22 nadväzuje na kontroly vzťahov a dohôd s dodávateľmi tým, že zabezpečuje priebežné monitorovanie a riadenie po začatí služby. Prepája sa s bezpečnosťou počas narušenia, riadením zraniteľností, súladom, riadením prístupu a bezpečným inžinierstvom.

DORA Articles 28 až 30 robia túto oblasť mimoriadne dôležitou pre finančné subjekty. Vyžadujú priebežné monitorovanie, registre dohôd s externými poskytovateľmi IKT služieb, rozlíšenie kritickosti, due diligence, práva na audit a kontrolu, práva na ukončenie, exit stratégie, úrovne služieb, pomoc pri incidentoch, spoluprácu s orgánmi a pri kritických alebo dôležitých funkciách ciele služieb, testovanie núdzových scenárov a spoluprácu pri penetračnom testovaní vedenom hrozbami, ak je relevantná.

Zenith Blueprint, fáza Controls in Action, Step 23, poskytuje štruktúru životného cyklu dodávateľa:

„Zostavte úplný zoznam aktuálnych dodávateľov a poskytovateľov služieb (5.19) a klasifikujte ich podľa prístupu k systémom, údajom alebo prevádzkovej kontrole.“

Pokračuje:

„Pri každom kritickom dodávateľovi identifikujte, či používa subdodávateľov (ďalších sprostredkovateľov), ktorí môžu pristupovať k vašim údajom alebo systémom.“

Praktické preskúmanie služby MDR sa má pri kritických prostrediach vykonávať štvrťročne a pri prostrediach s nižším rizikom aspoň raz ročne. Agenda má zahŕňať plnenie SLA podľa závažnosti, eskalované upozornenia, skutočne pozitívne nálezy, falošne pozitívne nálezy, zmeškané eskalácie, stav zdrojov logov, zmeny privilegovaného prístupu, nové integrácie, nové regióny, subdodávateľov, ďalších sprostredkovateľov, zmeny detekčných pravidiel, výkonnosť podpory pri incidentoch, požiadavky na dôkazy, otvorené riziká, nápravné opatrenia a pripravenosť na ukončenie spolupráce.

Toto nie je mikromanažment. Je to uisťovacia slučka, ktorá preukazuje, že organizácia aktívne riadi kritického bezpečnostného dodávateľa.

Mapovanie krížového súladu: jeden súbor kontrol MDR, päť auditných diskusií

Hodnota ISO/IEC 27001:2022 spočíva v tom, že organizáciám poskytuje jeden konzistentný cyklus ISMS pre viacero diskusií o súlade. Ten istý dôkazový balík dohľadu nad MDR možno mapovať na NIS2, DORA, GDPR, NIST CSF 2.0 a COBIT 2019.

NIST CSF 2.0 je užitočný na komunikáciu. Jeho funkcia GOVERN vyžaduje, aby boli právne, regulačné, zmluvné a súkromnoprávne povinnosti pochopené a riadené, roly a právomoci definované, kybernetické riziko integrované do podnikového riadenia rizík a dodávateľské riziká komunikované a monitorované.

COBIT 2019 je užitočný pre manažment a uistenie. Audítori orientovaní na COBIT sa často menej zameriavajú na jednu kontrolu a viac na to, či ciele správy a riadenia, riadenie služieb, vlastníctvo rizika a monitorovanie výkonnosti fungujú ako systém.

Ako budú audítori testovať dohľad nad poskytovateľom MDR

Rôzni audítori používajú rôzne pohľady, ale všetci chcú dôkazy, že organizácia riadi tento vzťah.

Audítor ISO/IEC 27001:2022 začne rozsahom, zainteresovanými stranami, posúdením rizík, vyhlásením o uplatniteľnosti, plánom ošetrenia rizík a prevádzkovými dôkazmi. Ak je MDR v rozsahu, audítor bude očakávať, že externe poskytované procesy sú riadené v rámci ISMS. Môže vzorkovať vzťahy s dodávateľmi, dohody s dodávateľmi, monitorovanie služieb dodávateľov, logovanie, monitorovanie, reakciu na incidenty, nakladanie s dôkazmi a riadenie prístupu.

Dozorný orgán podľa DORA sa zameria na prevádzkovú odolnosť a systémové riziko. Môže detailne skúmať posúdenie kritickosti, register IKT služieb, analýzu rizika koncentrácie, exit stratégiu, klasifikáciu incidentov, práva na audit a dôkazy, že poskytovateľ MDR dokáže podporiť regulačné oznámenie.

Audítor GDPR alebo hodnotiteľ ochrany súkromia sa zameria na správu a riadenie vzťahu prevádzkovateľ – sprostredkovateľ. Vyžiada si DPA, due diligence sprostredkovateľa, kontroly ďalších sprostredkovateľov, ochranné opatrenia pre logy obsahujúce osobné údaje, kontroly uchovávania, záznamy posúdenia porušenia ochrany osobných údajov a dôkazy podporujúce Article 32.

Audítor COBIT alebo ISACA preskúma dôkazy správy a riadenia: vlastníctvo dodávateľského rizika, pracovný tok obstarávania, zápisnice z preskúmania služieb, sledovanie problémov SLA, nápravné opatrenia, kvalitu dôkazov a či manažment dostáva zmysluplné metriky.

Najvýrečnejšia auditná požiadavka je jednoduchá: „Ukážte mi jedno upozornenie MDR od detekcie po uzavretie.“ Ak viete ukázať zmluvné očakávanie, zdroj logov, upozornenie, eskaláciu, rozhodnutie, zabezpečenie dôkazov, posúdenie súkromia, nápravu a reportovanie manažmentu, váš dohľad nad MDR je zrelý. Ak viete ukázať iba ticket dodávateľa, máte monitorovanie, ale slabú správu a riadenie.

Reportovanie manažmentu: predstavenstvo nepotrebuje paketové záznamy

NIS2 aj DORA kladú zodpovednosť na úroveň riadiaceho orgánu. Členovia predstavenstva a vrcholový manažment nepotrebujú surovú telemetriu. Potrebujú metriky dohľadu nad MDR relevantné pre riziko.

Užitočný štvrťročný dashboard MDR zahŕňa:

• Kritické zdroje logov zaradené do služby oproti očakávaným.
• Percento kritických aktív pokrytých MDR.
• Upozornenia s vysokou závažnosťou podľa kategórie a podnikovej služby.
• Priemerný čas od detekcie po oznámenie zákazníkovi.
• Priemerný čas od potvrdenia zákazníkom po rozhodnutie.
• Porušenia SLA a nevyriešené kroky poskytovateľa.
• Stav revízie účtov poskytovateľa s privilegovaným prístupom.
• Zmeny subdodávateľov alebo ďalších sprostredkovateľov.
• Incidenty vyžadujúce právne, regulačné alebo zákaznícke posúdenie oznamovania.
• Implementované získané poznatky.

Tento dashboard má vstupovať do preskúmania ISMS manažmentom, aktualizácií ošetrenia rizík a preskúmania dodávateľa. Podľa ISO/IEC 27001:2022 musí vedenie zabezpečiť, aby bol ISMS zosúladený so strategickým smerovaním, zdroje boli dostupné, zodpovednosti pridelené, komunikácia fungovala a dochádzalo k neustálemu zlepšovaniu. Metriky MDR sú praktickým spôsobom, ako ukázať, že outsourcované bezpečnostné operácie riadi manažment, nie iba administrátori nástrojov.

Bežné nedostatky dohľadu nad MDR, ktoré treba odstrániť pred auditmi v roku 2026

Najčastejšie medzery sú bežné zlyhania správy a riadenia.

Po prvé, organizácie zabúdajú, že poskytovatelia MDR môžu spracúvať osobné údaje. Bezpečnostné logy sa niekedy považujú za „technické údaje“, ale môžu obsahovať osobné údaje a občas aj citlivý obsah. Analýza rolí podľa GDPR a ustanovenia pre sprostredkovateľov majú byť dokončené pred onboardingom, nie počas porušenia ochrany osobných údajov.

Po druhé, uchovávanie logov sa predpokladá namiesto toho, aby bolo zmluvne dohodnuté. Ak regulačné, forenzné alebo zákaznícke povinnosti vyžadujú dôkazy za obdobie niekoľkých mesiacov, model uchovávania MDR a SIEM to musí podporovať. Požiadavka politiky pre MSP na 12-mesačné uchovávanie logov poskytovateľom je praktickou základnou úrovňou pre mnohé prostredia.

Po tretie, prístup tretích strán je nadmerne permisívny. Účty poskytovateľov majú byť pomenované, chránené MFA, monitorované, preskúmavané a tam, kde je to možné, časovo obmedzené. Zdieľané účty a nespravované administrátorské relácie vytvárajú auditné riziko aj riziko pri reakcii na incidenty.

Po štvrté, prahové hodnoty incidentov sú nejasné. Závažnosť MDR automaticky neznamená právny incident, závažný incident súvisiaci s IKT podľa DORA, významný incident podľa NIS2 ani porušenie ochrany osobných údajov podľa GDPR. Playbook musí definovať, kto robí každé rozhodnutie.

Po piate, subdodávatelia sú neviditeľní. Ak poskytovateľ MDR zmení analytické platformy, regióny podpory alebo ďalších sprostredkovateľov, mení sa rizikový profil zákazníka. Predchádzajúci písomný súhlas a pravidelné preskúmanie sú nevyhnutné.

Po šieste, preskúmania služieb sa zameriavajú iba na objem ticketov. Zrelé preskúmania skúmajú zmeškané upozornenia, zmeny ladenia, stav zdrojov logov, získavanie dôkazov, prístup poskytovateľa, spoluprácu pri incidentoch a zmluvné povinnosti.

Ďalšie kroky: pripravte svojho poskytovateľa MDR na audit s Clarysec

Ak je váš poskytovateľ MDR už v prevádzke, nečakajte, kým regulátor, zákaznícky audítor alebo incident odhalí, že vaše dôkazy sú neúplné. Začnite jedným nedávnym upozornením a vytvorte stopu. Potom klasifikujte poskytovateľa, preskúmajte zmluvu, overte logovanie, otestujte eskaláciu, potvrďte ustanovenia pre sprostredkovateľov, preskúmajte prístup a naplánujte monitorovanie dodávateľa.

Clarysec vám môže pomôcť rýchlo to prevádzkovo zaviesť pomocou:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint na fázovanú implementáciu vrátane Step 19 pre overenie logovania, monitorovania a prístupu a Step 23 pre kontroly riadenia dodávateľov a incidentov.
• Zenith Controls: The Cross-Compliance Guide Zenith Controls na mapovanie kontrol ISO/IEC 27002:2022 5.19, 5.22 a 8.15 na auditné očakávania NIS2, DORA, GDPR, NIST a COBIT.
• Šablóny politík Clarysec vrátane Politika reakcie na incidenty, Politika bezpečnosti tretích strán a dodávateľov, Politika logovania a monitorovania, Politika reakcie na incidenty - MSP, Politika bezpečnosti tretích strán a dodávateľov - MSP, Politika logovania a monitorovania - MSP a Politika ochrany údajov a súkromia - MSP.

MDR je jednou z najhodnotnejších bezpečnostných investícií, ktoré môže organizácia urobiť. V roku 2026 sa táto hodnota musí preukázať správou a riadením, dôkazmi a zodpovedným dohľadom. Ak chcete praktický balík dohľadu nad MDR mapovaný na ISO/IEC 27001:2022, NIS2, DORA a GDPR Article 32, Clarysec vám ho pomôže vybudovať skôr, než sa ďalšie upozornenie zmení na ďalšie auditné zistenie.