Nadzor nad pružateljem MDR usluge za NIS2, DORA i GDPR

U 02:13 u ponedjeljak ujutro pružatelj MDR usluge otvara upozorenje visoke ozbiljnosti: nemoguće putovanje, sumnjiva pravila poštanskog sandučića i povlašteni račun korišten s neupravljanog krajnjeg uređaja. SOC analitičar eskalira slučaj putem portala za prijave. Vaš voditelj IT-a spava. Financijski direktor prima upozorenje o phishingu od kontakta u banci prije nego što se aktivira interni kanal za incidente. Do 07:30 CISO se suočava s tri neugodna pitanja.

Tko je imao ovlast proglasiti incident?

Možemo li dokazati da je pružatelj MDR usluge imao odgovarajuće dnevničke zapise, da ih je zadržavao dovoljno dugo i da je očuvao dokaze?

Ako je pristupljeno osobnim podacima, može li pravna funkcija ispuniti rokove za procjenu povrede prema GDPR dok operativni timovi pripremaju prijavu prema NIS2 ili DORA?

Mjesec dana poslije vanjski revizor traži iste dokaze, ali drugim tonom. PDF izvješće pružatelja MDR usluge korisno je, ali nije dovoljno. Revizor traži sirove podatke upozorenja, potpune dnevničke zapise, revizijski trag eskalacije, interni zapisnik odluka, zapis o pregledu dobavljača i dokaz da je organizacija mogla neovisno provjeriti što se dogodilo.

To je problem nadzora nad pružateljem MDR usluge u 2026. Organizacije povjeravaju otkrivanje i odgovor vanjskim pružateljima jer je interni kapacitet SOC-a skup, zapošljavanje je zahtjevno, a aktivnost prijetnji neprekidna. No ugovaranje otkrivanja s vanjskim pružateljem ne znači prijenos odgovornosti. Prema NIS2, upravljačka tijela ostaju odgovorna za odobravanje i nadzor mjera upravljanja rizicima kibernetičke sigurnosti. Prema DORA, financijski subjekti ostaju u potpunosti odgovorni za IKT rizik trećih strana, uključujući kritične IKT usluge, potporu pri incidentima, prava na reviziju, podugovaranje i izlaz. Prema GDPR, voditelji obrade moraju dokazati odgovarajuću sigurnost obrade, osobito kada izvršitelji obrade postupaju s telemetrijom, podacima krajnjih uređaja, korisničkim identifikatorima, IP adresama, sadržajem e-pošte, dnevničkim zapisima ili forenzičkim slikama.

Praktični nedostatak rijetko je samo MDR ugovor. To je lanac dokaza između ugovora i aktivne usluge: usmjeravanje upozorenja, privilegirani pristup, zadržavanje dnevničkih zapisa, pragovi eskalacije, dokazi o incidentu, transparentnost podizvođača, odredbe o izvršitelju obrade, pregledi usluge, stolne vježbe i izvješćivanje upravljačkog tijela.

Dokaziv program nadzora nad pružateljem MDR usluge treba jedan operativni model koji zadovoljava više revizijskih razgovora. ISO/IEC 27001:2022 pruža tu okosnicu.

Nadzor nad MDR-om počinje odgovornošću, a ne SOC konzolom

Česta je pogreška uvođenje MDR-a tretirati kao tehnički projekt: implementirati EDR agente, proslijediti dnevničke zapise identiteta, konfigurirati upozorenja, dogovoriti Teams ili Slack kanal i pustiti uslugu u rad. To može poboljšati otkrivanje, ali ne dokazuje upravljanje.

NIS2 to pitanje izričito postavlja. Ključni i važni subjekti moraju provoditi odgovarajuće i razmjerne tehničke, operativne i organizacijske mjere upravljanja rizicima kibernetičke sigurnosti. Članak 21. uključuje analizu rizika, postupanje s incidentima, neprekidnost poslovanja, sigurnost opskrbnog lanca, kibernetičku higijenu, kontrolu pristupa, upravljanje imovinom, kriptografiju i višefaktorsku autentifikaciju. Članak 20. podiže to na razinu odgovornosti upravljačkog tijela, zahtijevajući odobrenje i nadzor tih mjera.

Pružatelji MDR usluga često istodobno obuhvaćaju nekoliko područja iz NIS2 članka 21.:

• Postupanje s incidentima, jer pružatelj provodi trijažu, eskalira i može preporučiti ograničavanje.
• Sigurnost opskrbnog lanca, jer je pružatelj izravni pružatelj usluge s operativnim utjecajem na sigurnost.
• Kontrola pristupa, jer pružatelj može pristupati konzolama, dnevničkim zapisima, alatima za krajnje uređaje ili cloud tenantima.
• Zapisivanje događaja i praćenje, jer otkrivanje ovisi o obuhvatu dnevničkih zapisa, zadržavanju i korelaciji.
• Kibernetička higijena, jer MDR nalazi često otkrivaju slabosti u zakrpavanju, identitetu ili konfiguraciji.
• Neprekidnost poslovanja, jer odgođeni odgovor može poremetiti kritične usluge.

Za financijske subjekte DORA dodatno zaoštrava operativni model. DORA se primjenjuje od 17. siječnja 2025. i zahtijeva upravljanje IKT rizicima, prijavljivanje incidenata, testiranje otpornosti, razmjenu informacija i upravljanje IKT rizicima trećih strana. Također pojašnjava da za financijske subjekte koji su identificirani i prema NIS2, DORA djeluje kao sektorski posebni pravni akt Unije za preklapajuće obveze kibernetičke sigurnosti. Regulirana banka, platna institucija, investicijsko društvo, osiguravatelj ili pružatelj usluga povezanih s kriptoimovinom ne može jednostavno reći: „Naš pružatelj MDR usluge to pokriva.” DORA očekuje da subjekt klasificira IKT incidente, upravlja pružateljima IKT usluga trećih strana i prati ih, održava registre aranžmana IKT usluga, definira ugovorna prava, testira otpornost, provodi analizu temeljnog uzroka i prijavljuje veće IKT incidente u fazama.

GDPR dodaje drugačiju perspektivu. Ako MDR telemetrija uključuje korisničke identifikatore, IP adrese, metapodatke e-pošte, zapise autentikacije, artefakte krajnjih uređaja ili datoteke koje sadrže osobne podatke, primjenjuju se načela sigurnosti i odgovornosti prema GDPR. Članak 5. uključuje cjelovitost, povjerljivost i odgovornost. Članak 32. o sigurnosti obrade postaje praktično pitanje dokaza: jesu li dnevnički zapisi zaštićeni, je li pristup ograničen, je li šifriranje korišteno gdje je primjereno, jesu li izvršitelji obrade pod nadzorom i može li organizacija dokazati što se dogodilo?

Poruka je dosljedna u sva tri režima: posao možete delegirati, ali odgovornost ne možete.

ISO/IEC 27001:2022 pretvara MDR u proces koji se može revidirati

Dobro implementiran sustav upravljanja informacijskom sigurnošću (ISMS) temeljen na ISO/IEC 27001:2022 pretvara nadzor nad pružateljem MDR usluge iz obećanja u upravljanju dobavljačima u operativni model temeljen na dokazima. Točka 8.1 posebno je važna jer zahtijeva da organizacije kontroliraju eksterno osigurane procese, proizvode i usluge relevantne za ISMS. MDR je upravo to: eksterno osiguran proces koji može utjecati na odgovor na incidente, privatnost, otpornost, regulatorno izvješćivanje i neprekidnost poslovanja.

Najvažnija područja Priloga A norme ISO/IEC 27001:2022 za nadzor nad MDR-om uključuju odnose s dobavljačima, sigurnosne zahtjeve u ugovorima s dobavljačima, upravljanje rizicima IKT opskrbnog lanca, praćenje usluga dobavljača, upravljanje incidentima, postupanje s dokazima, zapisivanje događaja, praćenje, kontrolu pristupa, privilegirani pristup, kriptografiju i pripravnost za neprekidnost poslovanja.

Clarysecov Zenith Controls: The Cross-Compliance Guide Zenith Controls referenca je za međusobno mapiranje usklađenosti u ovom području. Mapira kontrole ISO/IEC 27002:2022 na druge zahtjeve, povezane kontrole, revizijska očekivanja i dokaze implementacije. Za nadzor nad MDR-om ključne su tri kontrole ISO/IEC 27002:2022: 5.19 za odnose s dobavljačima, 5.22 za praćenje usluga dobavljača i upravljanje promjenama te 8.15 za zapisivanje događaja. Podržavaju ih 5.20 ugovori s dobavljačima, 5.21 sigurnost IKT opskrbnog lanca, 5.24 do 5.28 upravljanje incidentima i postupanje s dokazima, 5.34 privatnost i osobni podaci (PII), 5.36 usklađenost, 8.16 aktivnosti praćenja, 8.17 sinkronizacija sistemskog vremena, 8.18 uporaba privilegiranih pomoćnih programa i 8.8 upravljanje tehničkim ranjivostima.

To je važno jer nalaz revizije MDR-a rijetko glasi „nema MDR-a”. Obično glasi ovako:

• Pružatelj MDR usluge nije klasificiran kao kritičan.
• Ugovorne odredbe nisu uključivale obavješćivanje o incidentima, pristup dokazima ili prava na reviziju.
• Dnevnički zapisi nisu zadržani dovoljno dugo za istragu prijavljenog događaja.
• Pristup pružatelja bio je dijeljen, trajan ili nije bio nadziran.
• Korisnik nije pregledavao učinkovitost MDR-a u odnosu na SLA-ove.
• Podizvođači ili podizvršitelji obrade nisu bili odobreni.
• Obveze prijave povrede osobnih podataka nisu bile usklađene s tijekovima rada za incidente.
• Dokazi nisu očuvani na forenzički uporabljiv način.
• Uprava nije imala metrike koje pokazuju smanjuje li MDR usluga rizik.

Zenith Controls jasno opisuje odnos između očekivanja prema dobavljačima i ugovora:

„5.19 postavlja sigurnosna očekivanja o tome kako dobavljači trebaju postupati s informacijama organizacije. 5.20 formalizira ta očekivanja osiguravanjem da ugovori ili sporazumi izričito uključuju sigurnosne odredbe, kao što su zahtjevi povjerljivosti, usklađenost sa sigurnosnim politikama i postupci obavješćivanja o incidentima. Bez 5.20 zahtjevi identificirani u 5.19 možda neće biti pravno provedivi.”

Za MDR je ta rečenica upravljačka lekcija. Ako ugovor ne zahtijeva da pružatelj zadržava dnevničke zapise, dostavlja dokaze, surađuje u incidentima, ograničava podugovaranje, podržava revizije i poštuje rokove eskalacije, SOC usluga može biti operativno korisna, ali revizijski slaba.

Što MDR ugovor mora dokazati prije prvog upozorenja

Dobar MDR ugovor nije samo komercijalna narudžbenica. On je kontrolni dokument. DORA članci 28. do 30. zahtijevaju da se IKT rizikom trećih strana upravlja tijekom cijelog životnog ciklusa, uključujući registre IKT ugovora, klasifikaciju kritičnosti, dubinsku analizu prije sklapanja ugovora, prava revizije i inspekcije, prava raskida, izlazne strategije, jasne opise usluga, razine usluga, lokacije pružanja usluge i obrade podataka, obveze zaštite podataka, pomoć pri incidentima i suradnju s nadležnim tijelima. NIS2 članak 21. zahtijeva sigurnost opskrbnog lanca za izravne dobavljače i pružatelje usluga. GDPR zahtijeva definirane uloge voditelja obrade i izvršitelja obrade, jamstva izvršitelja obrade, odredbe o zaštiti podataka i dokaze o sigurnosti obrade.

Clarysecova biblioteka politika prevodi te obveze u praktične ugovorne i operativne zahtjeve. U Enterprise Incident Response Policy Politici odgovora na incidente, MDR se izričito tretira kao uređena sposobnost treće strane za incidente:

„Integracija s uslugama trećih strana, uključujući Managed Detection and Response (MDR), Security Incident and Event Management (SIEM) i pružatelje forenzičke analize, mora biti uređena jasno definiranim sporazumima o razini usluge (SLA) i odredbama o povjerljivosti.”

Ta je odredba važna jer pružatelji MDR usluga često primaju vrlo osjetljive informacije prije nego što organizacija zna je li incident prijavljiv. Telemetrija može uključivati korisnička imena, putanje datoteka, predmete e-pošte, interne nazive računala, IP adrese, mrežne dijagrame i pokazatelje kompromitacije. Odredbe o povjerljivosti štite organizaciju tijekom istrage i podupiru odgovornost prema GDPR.

Enterprise Third party and supplier security policy Politika sigurnosti trećih strana i dobavljača dodaje dvije odredbe koje revizori očekuju vidjeti pri pregledu nadzora nad MDR-om:

„Prava na reviziju, inspekciju i zahtjev za sigurnosnim dokazima”

i:

„Korištenje podizvođača podliježe prethodnoj pisanoj suglasnosti”

Za SME-ove se isto načelo upravljanja smanjuje po opsegu, ali se ne uklanja. Third-Party and Supplier Security Policy - SME Politika sigurnosti trećih strana i dobavljača - SME zahtijeva načelo najmanjih privilegija:

„Dobavljačima se smije dodijeliti pristup samo minimalnim sustavima i podacima potrebnima za obavljanje njihove funkcije.”

Također zahtijeva:

„Ograničenja daljnjeg podugovaranja bez odobrenja”

Te su odredbe osobito relevantne za MDR. Mnogi pružatelji koriste višerazinske SOC timove, dobavljače platformi, partnere za obavještajne podatke o prijetnjama, usluge analitike u oblaku ili regionalno osoblje za podršku. Ako nizvodne strane mogu pristupati korisničkim dnevničkim zapisima ili osobnim podacima, korisnik treba mehanizme vidljivosti i odobravanja. U terminima DORA, to je dio nadzora nad podugovaranjem i rizikom koncentracije. U terminima GDPR, to je upravljanje podizvršiteljima obrade. U terminima NIS2, to je upravljanje rizicima opskrbnog lanca.

Ključni kontrolni popis za nadzor nad MDR-om

Dokaziv odnos s pružateljem MDR usluge mora biti provjerljiv. Sljedeći kontrolni popis objedinjuje ugovorne, operativne i dokazne zahtjeve u jedinstveni prikaz kontrola.

Ovaj kontrolni popis treba ugraditi u nabavu, uvođenje, periodični pregled i testiranje incidenata. Ako bilo koja stavka nedostaje, organizacija je mora tretirati kao rizik dobavljača, a ne kao administrativni nedostatak.

Sedam domena dokaza koje revizori očekuju

Kako bi nadzor nad MDR-om bio spreman za reviziju, Clarysec preporučuje izradu MDR datoteke dokaza organizirane u sedam domena. Ta datoteka mora biti dio ISMS-a, a ne mapa nabave koju nitko ne pregledava.

Ova tablica mijenja razgovor s pružateljem. Umjesto pitanja „Pratite li nas?”, organizacija pita: „Možemo li svakog tromjesečja dokazati da MDR usluga ostaje učinkovita, usklađena i usklađena s našim apetitom za rizik?”

Zapisivanje događaja povezuje otkrivanje i dokaze usklađenosti

MDR bez pouzdanog zapisivanja događaja jest nagađanje ugovoreno s vanjskim pružateljem. Pružatelj može otkriti neke prijetnje, ali organizacija ne može dokazati opseg, vremenski slijed, temeljni uzrok ili učinak.

Kontrola ISO/IEC 27002:2022 8.15 odnosi se na zapisivanje događaja. Zenith Controls klasificira zapisivanje događaja kao detektivnu kontrolu koja podupire povjerljivost, cjelovitost i dostupnost, usklađenu s konceptom kibernetičke sigurnosti Detect i sposobnošću upravljanja događajima informacijske sigurnosti. Ona izravno povezuje zapisivanje događaja s aktivnostima praćenja, procjenom događaja, odgovorom na incidente, naučenim lekcijama, privilegiranim pristupom, sinkronizacijom sistemskog vremena, kontrolom pristupa, privatnošću, prikupljanjem dokaza, upravljanjem ranjivostima i praćenjem fizičke sigurnosti.

Zato je zapisivanje događaja središnje za dokaze prema NIS2, DORA i GDPR članku 32. Prijavljivanje značajnih incidenata prema NIS2 članku 23. zahtijeva rano upozorenje u roku od 24 sata od saznanja, obavijest u roku od 72 sata i završno izvješće najkasnije mjesec dana nakon obavijesti. Prijavljivanje većih IKT incidenata prema DORA zahtijeva klasifikaciju, eskalaciju, komunikaciju, analizu temeljnog uzroka i završno izvješćivanje. Odgovornost prema GDPR zahtijeva da organizacije dokažu što se dogodilo s osobnim podacima i jesu li sigurnosne mjere bile odgovarajuće.

Clarysecova Logging and Monitoring Policy - SME Politika zapisivanja događaja i praćenja - SME pruža jednostavnu ugovornu kontrolu za manje organizacije koje koriste vanjske pružatelje:

„Ugovori moraju zahtijevati od pružatelja da zadržavaju dnevničke zapise najmanje 12 mjeseci i omoguće pristup na zahtjev”

Za poslovna okruženja, Logging and Monitoring Policy Politika zapisivanja događaja i praćenja dodaje zahtjev operativne integracije:

„Moraju dostaviti podatke dnevnika na zahtjev ili se integrirati s organizacijskom SIEM/platformom za agregaciju dnevničkih zapisa.”

Te odredbe rješavaju ponavljajući problem odgovora na incidente: tijekom istrage pružatelj MDR usluge kaže da je događaj stariji od prozora pretraživog zadržavanja, da su dnevnički zapisi dostupni samo putem plaćenog forenzičkog izvoza ili da korisnikov SIEM ne sadrži obogaćenja pružatelja i radnje analitičara. Ako pristup dnevničkim zapisima nije unaprijed definiran, vremenski slijed incidenta postaje fragmentiran.

Snažan MDR model zapisivanja događaja mora definirati obvezne izvore dnevničkih zapisa, vrste događaja, razdoblja zadržavanja, zaštitu cjelovitosti, odobrenja pristupa, sinkronizaciju vremena, izvozne formate i pravila korelacije između platformi korisnika i pružatelja. Mora obuhvatiti i radnje pružatelja, uključujući promjene detekcijskih pravila, naredbe izolacije krajnjih uređaja, administrativni pristup, bilješke analitičara i izvoze dokaza.

Potporni ISO standardi dodatno potvrđuju taj pristup. ISO/IEC 27035-1:2023 i ISO/IEC 27035-2:2023 povezuju zapisivanje događaja s otkrivanjem incidenata, trijažom i centraliziranom analizom. ISO/IEC 27701:2021 dodaje zapisivanje događaja specifično za privatnost aktivnosti obrade osobnih podataka (PII). ISO/IEC 27017:2021 i ISO/IEC 27018:2020 dodaju očekivanja za zapisivanje događaja u oblaku i za osobne podatke u oblaku, osobito kada pružatelji obrađuju korisničke podatke u javnim cloud okruženjima. ISO/IEC 27005:2024 tretira nedostatno zapisivanje događaja kao pitanje obrade rizika, a ne samo kao prazninu u alatima.

Odgovor na incidente: MDR može eskalirati, ali uprava mora odlučiti

Pružatelji MDR usluga otkrivaju i savjetuju. Odgovorna organizacija proglašava incidente, procjenjuje regulatorni učinak, komunicira s nadležnim tijelima i odlučuje je li potrebna prijava povrede osobnih podataka.

Ta je razlika važna jer ozbiljnost MDR-a ne znači automatski značajan incident prema NIS2, veći IKT incident prema DORA ili povredu osobnih podataka prema GDPR. Pružatelj može označiti upozorenje kao „visoka ozbiljnost”, ali organizacija mora odlučiti jesu li pogođene kritične usluge, jesu li osobni podaci kompromitirani, treba li obavijestiti klijente, treba li obavijestiti regulatore i mora li uprava odobriti mjeru ograničavanja s operativnim utjecajem.

Clarysecova Incident Response Policy - SME Politika odgovora na incidente - SME izravna je:

„Treće strane moraju postupati u skladu s potpisanim ugovorima, koji moraju uključivati odredbe o prijavi povrede osobnih podataka i obveze suradnje pri odgovoru.”

Ta je odredba mjesto na kojem se dokazi za GDPR članak 32. susreću s operativnim odgovorom na incidente. Ako pružatelj MDR usluge uoči sumnju na iznošenje podataka s krajnjeg uređaja koji sadrži osobne podatke, pružatelj mora znati koliko brzo obavijestiti, koga obavijestiti, koje dokaze očuvati i kako podržati procjenu voditelja obrade.

Clarysecov Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint daje metodu testiranja. U fazi Controls in Action, Step 19, Zenith Blueprint upućuje timove da operativno provjere zapisivanje događaja i praćenje:

„Odaberite nedavni incident ili događaj i pokažite kako ste ga pratili pomoću svojih dnevničkih zapisa. Ako se koriste značajke cjelovitosti dnevničkih zapisa (npr. provjera sažetka), dokumentirajte i to. Potvrdite da upozoravanje funkcionira (npr. neuspjele prijave ili eskalacije privilegija pokreću upozorenja).”

Isti korak obrađuje identitet i privilegirani pristup:

„Za privilegirane račune provjerite da se MFA provodi, da su administratorske uloge odvojene (računi u stilu admin_john koriste se samo za administratorske zadatke) i da postoji ažuran popis privilegiranih korisnika.”

U MDR kontekstu popis privilegiranih korisnika mora uključivati račune pružatelja, a ne samo zaposlenike. Ako pružatelj MDR usluge ima pristup konzoli, prava izolacije krajnjih uređaja, administratorska prava nad EDR-om ili pristup za čitanje osjetljivih dnevničkih zapisa, ti računi pripadaju u pregled.

Step 23 Zenith Blueprinta zatim daje strukturu testa za incidente i dobavljače:

„Odaberite nedavni događaj ili provedite stolnu vježbu kako biste provjerili svoj plan. Zabilježite sve odluke, uloge i komunikacije (5.26) te ažurirajte plan naučenim lekcijama (5.27). Potvrdite da postoje postupci za očuvanje forenzičkih dokaza (5.28), uključujući snimke dnevničkih zapisa, sigurnosne kopije i sigurnu izolaciju pogođenih sustava.”

Realistična stolna vježba treba uključiti pružatelja MDR usluge. Upotrijebite scenarij kao što su kompromitirani privilegirani račun, izolacija krajnjeg uređaja, sumnja na pristup poštanskom sandučiću, moguća izloženost podataka o plaćama i eskalacija upozorenja izvan radnog vremena. Test treba provjeriti počinje li vrijeme pružatelja MDR usluge teći od otkrivanja, obavijesti korisniku ili potvrde korisnika. Ta je razlika važna kada regulatorni rokovi ovise o trenutku saznanja i točkama odlučivanja.

Izradite MDR paket nadzora za jedno upozorenje u 90 minuta

Brz način za otkrivanje praznina jest odabrati jedno nedavno MDR upozorenje visoke ozbiljnosti i izraditi dokazni trag na jednoj stranici. Ova praktična vježba dobro funkcionira prije revizija, pregleda upravnog odbora i obnova ugovora.

1. Počnite s prijavom upozorenja. Zabilježite vremensku oznaku, detekcijsko pravilo, pogođenu imovinu, korisnika, ozbiljnost, bilješke MDR analitičara i put eskalacije.
2. Dohvatite ugovornu odredbu ili SLA koji pokazuje očekivano vrijeme odgovora za tu ozbiljnost.
3. Dohvatite popis izvora dnevničkih zapisa koji dokazuje koji su sustavi hranili upozorenje, kao što su EDR, pružatelj identiteta, vatrozid, sigurnosni pristupnik e-pošte i revizijski zapisi u oblaku.
4. Potvrdite da se dnevnički zapisi zadržavaju prema politici i da se povijesni događaj još može dohvatiti.
5. Provjerite je li MDR analitičar pristupio bilo kojem korisničkom okruženju. Ako jest, zabilježite imenovani račun, MFA dokaz, zapise sesije i odobrenje.
6. Dokumentirajte odluku na strani korisnika: događaj zatvoren, incident proglašen, pokrenuta pravna procjena, provedeno ograničavanje ili rizik prihvaćen.
7. Ako osobni podaci mogu biti uključeni, zabilježite analizu uloga prema GDPR, vlasnika procjene povrede i jesu li pokrenute obveze obavješćivanja izvršitelja obrade.
8. Zaključite naučenim lekcijama: podešavanje, nova detekcija, promjena pristupa, ažuriranje operativnih uputa ili problem SLA-a dobavljača.

Ovaj trag jednog upozorenja snažan je jer povezuje ugovor, zapisivanje događaja, pristup, odgovor na incidente, privatnost i nadzor uprave u jedan lanac dokaza. Ako ga ne možete izraditi za nedavno upozorenje, vjerojatno ga nećete moći izraditi ni pod regulatornim pritiskom.

Praćenje dobavljača mjesto je gdje većina MDR programa slabi

Mnoge organizacije provode dubinsku analizu dobavljača prije potpisivanja MDR ugovora, a zatim stanu. To nije dovoljno za ISO/IEC 27001:2022, NIS2, DORA ili GDPR. MDR usluge kontinuirano se mijenjaju: nova detekcijska pravila, novi analitički timovi, novi podizvršitelji obrade, nove podatkovne regije, nove EDR mogućnosti, nove integracije, novi izvori obavještajnih podataka o prijetnjama i novi modeli podrške.

Kontrola ISO/IEC 27002:2022 5.22 obrađuje praćenje, pregled i upravljanje promjenama usluga dobavljača. Zenith Controls objašnjava da 5.22 nadograđuje kontrole odnosa s dobavljačima i ugovora osiguravanjem kontinuiranog praćenja i upravljanja nakon pokretanja usluge. Povezuje se sa sigurnošću tijekom poremećaja, upravljanjem ranjivostima, usklađenošću, kontrolom pristupa i sigurnim inženjeringom.

DORA članci 28. do 30. čine to osobito važnim za financijske subjekte. Zahtijevaju stalno praćenje, registre aranžmana s IKT trećim stranama, razlikovanje kritičnosti, dubinsku analizu dobavljača, prava na reviziju i inspekciju, prava raskida, izlazne strategije, razine usluga, pomoć pri incidentima, suradnju s nadležnim tijelima te, za kritične ili važne funkcije, ciljeve usluga, testiranje planova za nepredviđene okolnosti i suradnju u penetracijskom testiranju vođenom prijetnjama gdje je relevantno.

Zenith Blueprint, u fazi Controls in Action, Step 23, pruža strukturu životnog ciklusa dobavljača:

„Sastavite potpuni popis trenutačnih dobavljača i pružatelja usluga (5.19) i klasificirajte ih prema pristupu sustavima, podacima ili operativnoj kontroli.”

Nastavlja:

„Za svakog kritičnog dobavljača utvrdite koristi li podizvođače (podizvršitelje obrade) koji mogu pristupati vašim podacima ili sustavima.”

Praktičan pregled MDR usluge treba provoditi tromjesečno za kritična okruženja i najmanje godišnje za okruženja nižeg rizika. Dnevni red treba uključivati usklađenost sa SLA-om prema ozbiljnosti, eskalirana upozorenja, stvarno pozitivne nalaze, lažno pozitivne rezultate, propuštene eskalacije, stanje izvora dnevničkih zapisa, promjene privilegiranog pristupa, nove integracije, nove regije, podizvođače, podizvršitelje obrade, promjene detekcijskih pravila, učinkovitost potpore pri incidentima, zahtjeve za dokazima, otvorene rizike, korektivne radnje i spremnost za izlaz.

To nije mikroupravljanje. To je petlja osiguranja koja dokazuje da organizacija aktivno upravlja kritičnim sigurnosnim dobavljačem.

Mapiranje međusobne usklađenosti: jedan skup MDR kontrola, pet revizijskih razgovora

Vrijednost ISO/IEC 27001:2022 jest u tome što organizacijama daje jedan koherentan ISMS ciklus za više razgovora o usklađenosti. Isti MDR paket dokaza nadzora može se mapirati na NIS2, DORA, GDPR, NIST CSF 2.0 i COBIT 2019.

NIST CSF 2.0 koristan je za komunikaciju. Njegova funkcija GOVERN zahtijeva da se razumiju i upravljaju pravne, regulatorne, ugovorne i privatnosne obveze, da se definiraju uloge i ovlasti, da se rizik kibernetičke sigurnosti integrira u upravljanje rizicima organizacije te da se rizici dobavljača komuniciraju i prate.

COBIT 2019 koristan je za upravljanje i osiguranje. Revizori usmjereni na COBIT često se manje fokusiraju na pojedinačnu kontrolu, a više na to funkcioniraju li ciljevi upravljanja, upravljanje uslugama, vlasništvo nad rizikom i praćenje učinkovitosti kao sustav.

Kako će revizori testirati nadzor nad pružateljem MDR usluge

Različiti revizori koriste različite perspektive, ali svi žele dokaze da organizacija kontrolira odnos.

Revizor ISO/IEC 27001:2022 počet će s opsegom, zainteresiranim stranama, procjenom rizika, Izjavom o primjenjivosti, planom obrade rizika i operativnim dokazima. Ako je MDR u opsegu, revizor će očekivati da su eksterno osigurani procesi kontrolirani u okviru ISMS-a. Može uzorkovati odnose s dobavljačima, ugovore s dobavljačima, praćenje usluga dobavljača, zapisivanje događaja, praćenje, odgovor na incidente, postupanje s dokazima i kontrolu pristupa.

Nadzorno tijelo prema DORA usredotočit će se na operativnu otpornost i sistemski rizik. Može detaljno pregledati procjenu kritičnosti, registar IKT usluga, analizu rizika koncentracije, izlaznu strategiju, klasifikaciju incidenata, prava na reviziju i dokaze da pružatelj MDR usluge može podržati regulatorno izvješćivanje.

Revizor za GDPR ili pregledavatelj privatnosti usredotočit će se na upravljanje odnosom voditelj obrade–izvršitelj obrade. Tražit će DPA, dubinsku analizu izvršitelja obrade, kontrole podizvršitelja obrade, zaštitne mjere za dnevničke zapise koji sadrže osobne podatke, kontrole zadržavanja, zapise procjene povrede i dokaze koji podupiru članak 32.

Revizor za COBIT ili ISACA pregledat će upravljačke dokaze: vlasništvo nad rizikom dobavljača, tijek rada nabave, zapisnike pregleda usluga, praćenje SLA problema, korektivne radnje, kvalitetu dokaza i prima li uprava smislene metrike.

Najotkrivajuće revizijsko pitanje jednostavno je: „Pokažite mi jedno MDR upozorenje od otkrivanja do zatvaranja.” Ako možete pokazati ugovorno očekivanje, izvor dnevničkih zapisa, upozorenje, eskalaciju, odluku, očuvanje dokaza, procjenu privatnosti, otklanjanje posljedica i izvješćivanje uprave, vaš nadzor nad MDR-om je zreo. Ako možete pokazati samo prijavu dobavljača, imate praćenje, ali slabo upravljanje.

Izvješćivanje uprave: upravnom odboru ne trebaju snimke paketa

NIS2 i DORA postavljaju odgovornost na razinu upravljačkog tijela. Upravni odbori i izvršni rukovoditelji ne trebaju sirovu telemetriju. Trebaju metrike nadzora nad MDR-om relevantne za rizik.

Korisna tromjesečna MDR nadzorna ploča uključuje:

• Kritične izvore dnevničkih zapisa uvedene u odnosu na očekivane.
• Postotak kritične imovine obuhvaćene MDR-om.
• Upozorenja visoke ozbiljnosti prema kategoriji i poslovnoj usluzi.
• Prosječno vrijeme od otkrivanja do obavijesti korisniku.
• Prosječno vrijeme od potvrde korisnika do odluke.
• Kršenja SLA-a i neriješene radnje pružatelja.
• Status pregleda privilegiranih računa pružatelja.
• Promjene podizvođača ili podizvršitelja obrade.
• Incidente koji zahtijevaju pravnu, regulatornu ili korisničku procjenu obavješćivanja.
• Implementirane naučene lekcije.

Ova nadzorna ploča treba se koristiti za preispitivanje ISMS-a od strane uprave, ažuriranja obrade rizika i pregled dobavljača. Prema ISO/IEC 27001:2022, vodstvo mora osigurati da je ISMS usklađen sa strateškim usmjerenjem, da su resursi dostupni, da su odgovornosti dodijeljene, da komunikacija funkcionira i da dolazi do kontinuiranog poboljšanja. MDR metrike praktičan su način da se pokaže kako su vanjski ugovorene sigurnosne operacije pod upravljanjem uprave, a ne prepuštene administratorima alata.

Česte slabosti nadzora nad MDR-om koje treba ukloniti prije revizija u 2026.

Najčešće praznine uobičajeni su neuspjesi upravljanja.

Prvo, organizacije zaboravljaju da pružatelji MDR usluga mogu obrađivati osobne podatke. Sigurnosni dnevnički zapisi ponekad se tretiraju kao „tehnički podaci”, ali mogu sadržavati osobne podatke i povremeno osjetljiv sadržaj. Analiza uloga prema GDPR i odredbe o izvršitelju obrade trebaju biti dovršene prije uvođenja, a ne tijekom povrede.

Drugo, zadržavanje dnevničkih zapisa pretpostavlja se umjesto da se ugovori. Ako regulatorne, forenzičke ili korisničke obveze zahtijevaju dokaze tijekom više mjeseci, MDR i SIEM model zadržavanja to mora podržati. Zahtjev SME politike za 12-mjesečno zadržavanje dnevničkih zapisa kod pružatelja praktična je polazna osnova za mnoga okruženja.

Treće, pristup trećih strana preširok je. Računi pružatelja trebaju biti imenovani, zaštićeni MFA-om, nadzirani, pregledavani i vremenski ograničeni gdje je izvedivo. Dijeljeni računi i neupravljane administratorske sesije stvaraju revizijski rizik i rizik za odgovor na incidente.

Četvrto, pragovi incidenata nejasni su. Ozbiljnost MDR-a ne znači automatski pravni incident, veći IKT incident prema DORA, značajan incident prema NIS2 ili povredu osobnih podataka prema GDPR. Operativne upute moraju definirati tko donosi svaku odluku.

Peto, podizvođači su nevidljivi. Ako pružatelj MDR usluge promijeni analitičke platforme, regije podrške ili nizvodne izvršitelje obrade, mijenja se slika rizika korisnika. Prethodna pisana suglasnost i periodični pregled ključni su.

Šesto, pregledi usluge fokusiraju se samo na volumen prijava. Zreli pregledi ispituju propuštena upozorenja, promjene podešavanja, stanje izvora dnevničkih zapisa, dohvat dokaza, pristup pružatelja, suradnju pri incidentima i ugovorne obveze.

Sljedeći koraci: učinite svog pružatelja MDR usluge spremnim za reviziju uz Clarysec

Ako je vaš pružatelj MDR usluge već aktivan, nemojte čekati regulatora, revizora korisnika ili incident da biste otkrili da su vam dokazi nepotpuni. Počnite s jednim nedavnim upozorenjem i izradite trag. Zatim klasificirajte pružatelja, pregledajte ugovor, provjerite zapisivanje događaja, testirajte eskalaciju, potvrdite odredbe o izvršitelju obrade, pregledajte pristup i zakažite praćenje dobavljača.

Clarysec vam može pomoći da to brzo operativno uredite pomoću:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint za faznu implementaciju, uključujući Step 19 za zapisivanje događaja, praćenje i provjeru pristupa te Step 23 za kontrole upravljanja dobavljačima i incidentima.
• Zenith Controls: The Cross-Compliance Guide Zenith Controls za mapiranje kontrola ISO/IEC 27002:2022 5.19, 5.22 i 8.15 na revizijska očekivanja za NIS2, DORA, GDPR, NIST i COBIT.
• Clarysec predlošci politika, uključujući Politiku odgovora na incidente, Politiku sigurnosti trećih strana i dobavljača, Politiku zapisivanja događaja i praćenja, Politiku odgovora na incidente - SME, Politiku sigurnosti trećih strana i dobavljača - SME, Politiku zapisivanja događaja i praćenja - SME i Politiku zaštite podataka i privatnosti - SME.

MDR je jedno od najvrjednijih sigurnosnih ulaganja koje organizacija može provesti. U 2026. ta se vrijednost mora dokazati kroz upravljanje, dokaze i odgovoran nadzor. Ako želite praktičan paket nadzora nad MDR-om mapiran na ISO/IEC 27001:2022, NIS2, DORA i GDPR članak 32., Clarysec vam može pomoći da ga izgradite prije nego što sljedeće upozorenje postane sljedeći nalaz revizije.