Nadzor nad ponudnikom MDR za NIS2, DORA in GDPR

Ob 02:13 v ponedeljek zjutraj ponudnik MDR odpre opozorilo visoke resnosti: nemogoče potovanje, sumljiva pravila poštnega predala in privilegirani račun, uporabljen z neupravljane končne točke. Analitik SOC zadevo eskalira prek portala za upravljanje zahtevkov. Vaš vodja IT spi. Finančni direktor prejme opozorilo banke o lažnem predstavljanju, še preden se aktivira notranji kanal za incidente. Ob 07:30 se vodja informacijske varnosti sooči s tremi neprijetnimi vprašanji.

Kdo je imel pooblastilo za razglasitev incidenta?

Ali lahko dokažemo, da je ponudnik MDR imel ustrezne dnevnike, jih hranil dovolj dolgo in ohranil dokazila?

Če je prišlo do dostopa do osebnih podatkov, ali lahko pravna služba izpolni roke za presojo kršitve po GDPR, medtem ko operativa pripravlja poročanje po NIS2 ali DORA?

Mesec dni pozneje zunanji presojevalec zahteva ista dokazila, le z drugačnim tonom. Poročilo ponudnika MDR v obliki PDF je uporabno, vendar ne zadostuje. Presojevalec želi surove podatke opozoril, popolne datoteke dnevnikov, eskalacijsko sled, notranji dnevnik odločitev, zapis pregleda dobavitelja in dokaz, da je organizacija lahko neodvisno preverila, kaj se je zgodilo.

To je izziv nadzora nad ponudnikom MDR v letu 2026. Organizacije zunanje izvajajo zaznavanje in odzivanje, ker so notranje zmogljivosti SOC drage, zaposlovanje je zahtevno, dejavnost groženj pa ne popušča. Vendar zunanje izvajanje zaznavanja ne pomeni zunanjega izvajanja odgovornosti. Po NIS2 organi upravljanja ostajajo odgovorni za odobritev in nadzor ukrepov za upravljanje tveganj kibernetske varnosti. Po DORA finančni subjekti ostajajo v celoti odgovorni za tveganja tretjih oseb na področju IKT, vključno s kritičnimi IKT-storitvami, podporo pri incidentih, pravicami do revizije, podizvajanjem in izstopom. Po GDPR morajo upravljavci dokazati ustrezno varnost obdelave, zlasti kadar obdelovalci obravnavajo telemetrijo, podatke končnih točk, uporabniške identifikatorje, naslove IP, vsebino e-pošte, dnevnike ali forenzične slike.

Praktična vrzel redko izhaja samo iz pogodbe MDR. Nastane v verigi dokazil med pogodbo in dejanskim izvajanjem storitve: usmerjanje opozoril, privilegirani dostop, hramba dnevnikov, pragovi eskalacije, dokazila o incidentih, preglednost podizvajalcev, klavzule za obdelovalce, pregledi storitev, namizne vaje in poročanje vodstvu.

Zagovorljiv program nadzora nad ponudnikom MDR potrebuje enoten operativni model, ki podpira več revizijskih pogovorov. ISO/IEC 27001:2022 zagotavlja to hrbtenico.

Nadzor MDR se začne z odgovornostjo, ne s konzolo SOC

Pogosta napaka je, da se uvedba MDR obravnava kot tehnični projekt: namestitev agentov EDR, posredovanje dnevnikov identitet, konfiguracija opozoril, dogovor o kanalu Teams ali Slack in prehod v produkcijo. To lahko izboljša zaznavanje, vendar ne dokazuje upravljanja.

NIS2 to vprašanje izrecno opredeljuje. Bistveni in pomembni subjekti morajo izvajati ustrezne in sorazmerne tehnične, operativne in organizacijske ukrepe za upravljanje tveganj kibernetske varnosti. Člen 21 vključuje analizo tveganj, obravnavanje incidentov, neprekinjeno poslovanje, varnost dobavne verige, kibernetsko higieno, nadzor dostopa, upravljanje sredstev, kriptografijo in večfaktorsko avtentikacijo. Člen 20 to dvigne na raven odgovornosti organov upravljanja ter zahteva odobritev in nadzor teh ukrepov.

Ponudniki MDR pogosto hkrati pokrivajo več področij iz NIS2 Člen 21:

• Obravnavanje incidentov, ker ponudnik izvaja triažo, eskalira in lahko priporoči zajezitev.
• Varnost dobavne verige, ker je ponudnik neposredni izvajalec storitev z operativnim vplivom na varnost.
• Nadzor dostopa, ker lahko ponudnik dostopa do konzol, dnevnikov, orodij končnih točk ali oblačnih najemnikov.
• Beleženje in spremljanje, ker je zaznavanje odvisno od pokritosti dnevnikov, hrambe in korelacije.
• Kibernetska higiena, ker ugotovitve MDR pogosto razkrijejo slabosti pri nameščanju popravkov, identitetah ali konfiguracijah.
• Neprekinjeno poslovanje, ker lahko zapoznel odziv prekine kritične storitve.

Za finančne subjekte DORA dodatno zaostri operativni model. DORA se uporablja od 17. januarja 2025 in zahteva upravljanje tveganj IKT, poročanje o incidentih, testiranje odpornosti, izmenjavo informacij in upravljanje tveganj tretjih oseb na področju IKT. Prav tako pojasnjuje, da za finančne subjekte, ki so opredeljeni tudi po NIS2, DORA deluje kot sektorski pravni akt Unije za prekrivajoče se obveznosti kibernetske varnosti. Regulirana banka, plačilna institucija, investicijsko podjetje, zavarovalnica ali ponudnik storitev v zvezi s kriptosredstvi ne more preprosto reči: »To ureja naš ponudnik MDR.« DORA od subjekta pričakuje razvrščanje IKT-incidentov, upravljanje in spremljanje tretjih ponudnikov IKT-storitev, vzdrževanje evidenc ureditev IKT-storitev, opredelitev pogodbenih pravic, testiranje odpornosti, izvajanje analize temeljnega vzroka in fazno poročanje o večjih incidentih, povezanih z IKT.

GDPR doda drugačen pogled. Če telemetrija MDR vključuje uporabniške identifikatorje, naslove IP, metapodatke e-pošte, avtentikacijske zapise, artefakte končnih točk ali datoteke z osebnimi podatki, se uporabljajo načela varnosti in odgovornosti po GDPR. Člen 5 vključuje celovitost, zaupnost in odgovornost. Člen 32 o varnosti obdelave postane praktično vprašanje dokazil: ali so bili dnevniki zaščiteni, ali je bil dostop omejen, ali je bilo uporabljeno šifriranje, kjer je bilo primerno, ali so bili obdelovalci upravljani in ali lahko organizacija dokaže, kaj se je zgodilo?

Sporočilo je v vseh treh režimih enako: delo lahko prenesete, odgovornosti pa ne.

ISO/IEC 27001:2022 spremeni MDR v preverljiv proces

Dobro uveden ISMS, zasnovan na ISO/IEC 27001:2022, spremeni nadzor nad ponudnikom MDR iz obljube upravljanja dobaviteljev v operativni model, ki temelji na dokazilih. Točka 8.1 je posebej pomembna, ker od organizacij zahteva nadzor nad zunanje zagotovljenimi procesi, proizvodi in storitvami, relevantnimi za ISMS. MDR je natanko to: zunanje zagotovljen proces, ki lahko vpliva na odziv na incidente, zasebnost, odpornost, regulativno poročanje in neprekinjeno poslovanje.

Najpomembnejša področja Priloge A ISO/IEC 27001:2022 za nadzor MDR vključujejo odnose z dobavitelji, varnostne zahteve v sporazumih z dobavitelji, upravljanje tveganj dobavne verige IKT, spremljanje storitev dobaviteljev, upravljanje incidentov, ravnanje z dokazili, beleženje, spremljanje, nadzor dostopa, privilegirani dostop, kriptografijo in pripravljenost za neprekinjeno poslovanje.

Clarysecov Zenith Controls: The Cross-Compliance Guide Zenith Controls je referenca za navzkrižno skladnost pri tem delu. Kontrole ISO/IEC 27002:2022 preslika na druge zahteve, povezane kontrole, revizijska pričakovanja in dokazila o implementaciji. Za nadzor MDR so osrednje tri kontrole ISO/IEC 27002:2022: 5.19 za odnose z dobavitelji, 5.22 za spremljanje storitev dobaviteljev in upravljanje sprememb ter 8.15 za beleženje. Podpirajo jih 5.20 sporazumi z dobavitelji, 5.21 varnost dobavne verige IKT, 5.24 do 5.28 upravljanje incidentov in ravnanje z dokazili, 5.34 zasebnost in osebno določljivi podatki, 5.36 skladnost, 8.16 dejavnosti spremljanja, 8.17 sinhronizacija časa, 8.18 uporaba privilegiranih pomožnih programov in 8.8 upravljanje tehničnih ranljivosti.

To je pomembno, ker revizijska ugotovitev pri MDR redko pravi »ni MDR«. Običajno ugotovi eno od naslednjega:

• Ponudnik MDR ni bil razvrščen kot kritičen.
• Pogodbene klavzule niso vključevale obveščanja o incidentih, dostopa do dokazil ali pravic do revizije.
• Dnevniki niso bili hranjeni dovolj dolgo za preiskavo prijavljenega dogodka.
• Dostop ponudnika je bil skupen, trajen ali nespremljan.
• Naročnik ni pregledoval uspešnosti MDR glede na SLA.
• Podizvajalci ali podobdelovalci niso bili odobreni.
• Obveznosti obveščanja o kršitvi varstva osebnih podatkov niso bile usklajene z delovnimi tokovi incidentov.
• Dokazila niso bila ohranjena na forenzično uporaben način.
• Vodstvo ni imelo kazalnikov, ki bi pokazali, ali je storitev MDR zmanjšala tveganje.

Zenith Controls jasno opredeljuje razmerje med pričakovanji do dobaviteljev in sporazumi:

»5.19 določa varnostna pričakovanja glede tega, kako morajo dobavitelji ravnati z informacijami organizacije. 5.20 ta pričakovanja formalizira tako, da zagotovi, da pogodbe ali sporazumi izrecno vključujejo varnostne klavzule, kot so zahteve glede zaupnosti, skladnost z varnostnimi politikami in postopki obveščanja o incidentih. Brez 5.20 zahteve, opredeljene v 5.19, morda niso pravno izvršljive.«

Za MDR je ta stavek lekcija upravljanja. Če pogodba od ponudnika ne zahteva hrambe dnevnikov, predložitve dokazil, sodelovanja pri incidentih, omejitve podizvajanja, podpore presojam in upoštevanja eskalacijskih rokov, je storitev SOC morda operativno uporabna, vendar revizijsko šibka.

Kaj mora pogodba MDR dokazati pred prvim opozorilom

Dobra pogodba MDR ni zgolj komercialni naročilni obrazec. Je kontrolni dokument. Členi 28 do 30 DORA zahtevajo upravljanje tveganj tretjih oseb na področju IKT skozi celoten življenjski cikel, vključno z evidencami pogodb IKT, razvrstitvijo kritičnosti, predpogodbenim skrbnim pregledom, pristopi k reviziji in inšpekciji, pravicami do odpovedi, izstopnimi strategijami, jasnimi opisi storitev, ravnmi storitev, lokacijami izvajanja storitve in obdelave podatkov, zavezami glede varstva podatkov, pomočjo pri incidentih in sodelovanjem z organi. NIS2 Člen 21 zahteva varnost dobavne verige za neposredne dobavitelje in izvajalce storitev. GDPR zahteva vloge upravljavca in obdelovalca, jamstva obdelovalca, klavzule o varstvu podatkov in dokazila o varnosti obdelave.

Clarysecova knjižnica politik te obveznosti prevaja v praktične pogodbene in operativne zahteve. V Enterprise Incident Response Policy Incident Response Policy je MDR izrecno obravnavan kot upravljana zmogljivost tretje osebe za obravnavanje incidentov:

»Integracija s storitvami tretjih oseb, vključno z upravljanim zaznavanjem in odzivanjem (MDR), upravljanjem varnostnih informacij in dogodkov (SIEM) ter ponudniki forenzične analize, mora biti urejena z jasno opredeljenimi sporazumi o ravni storitev (SLA) in določbami o nerazkrivanju informacij.«

Ta klavzula je pomembna, ker ponudniki MDR pogosto prejmejo zelo občutljive informacije, preden organizacija ve, ali je incident prijavljiv. Telemetrija lahko vključuje uporabniška imena, poti datotek, zadeve e-pošte, notranja gostiteljska imena, naslove IP, omrežne diagrame in kazalnike kompromitacije. Določbe o nerazkrivanju informacij varujejo organizacijo med preiskavo in podpirajo odgovornost po GDPR.

Enterprise Third party and supplier security policy Third party and supplier security policy dodaja dve klavzuli, ki ju presojevalci pričakujejo pri pregledu nadzora MDR:

»Pravice do revizije, pregleda in zahteve po varnostnih dokazilih«

in:

»Uporaba podizvajalcev s predhodnim pisnim soglasjem«

Za MSP se isto načelo upravljanja prilagodi obsegu, vendar se ne odpravi. Third-Party and Supplier Security Policy - SME Third-Party and Supplier Security Policy - SME zahteva načelo najmanjših privilegijev:

»Dobaviteljem mora biti odobren dostop samo do minimalnega nabora sistemov in podatkov, potrebnih za izvajanje njihove funkcije.«

Zahteva tudi:

»Omejitve nadaljnjega podizvajanja brez odobritve«

Te klavzule so posebej relevantne za MDR. Številni ponudniki uporabljajo večnivojske ekipe SOC, dobavitelje platform, partnerje za obveščevalne podatke o grožnjah, storitve analitike v oblaku ali regionalno podporno osebje. Če lahko nadaljnje osebe dostopajo do naročnikovih dnevnikov ali osebnih podatkov, naročnik potrebuje mehanizme vidnosti in odobritve. V izrazoslovju DORA je to del nadzora nad podizvajanjem in tveganjem koncentracije. V izrazoslovju GDPR je to upravljanje podobdelovalcev. V izrazoslovju NIS2 je to upravljanje tveganj dobavne verige.

Ključni kontrolni seznam za nadzor MDR

Zagovorljivo razmerje s ponudnikom MDR mora biti preverljivo. Naslednji kontrolni seznam združuje pogodbene, operativne in dokazilne zahteve v enoten pogled kontrol.

Ta kontrolni seznam mora biti vgrajen v nabavo, uvedbo, periodične preglede in testiranje incidentov. Če kateri koli element manjka, ga mora organizacija obravnavati kot tveganje dobavitelja, ne kot administrativno pomanjkljivost.

Sedem področij dokazil, ki jih pričakujejo presojevalci

Da bi bil nadzor MDR pripravljen na presojo, Clarysec priporoča vzpostavitev datoteke dokazil MDR, organizirane v sedem področij. Ta datoteka mora biti del ISMS, ne pa nabavna mapa, ki je nihče ne pregleduje.

Ta tabela spremeni pogovor s ponudnikom. Namesto vprašanja »Ali nas spremljate?« organizacija vpraša: »Ali lahko vsako četrtletje dokažemo, da storitev MDR ostaja učinkovita, skladna in usklajena z našim apetitom po tveganju?«

Beleženje je most med zaznavanjem in dokazili o skladnosti

MDR brez zanesljivega beleženja je zunanje ugibanje. Ponudnik lahko zazna nekatere grožnje, vendar organizacija ne more dokazati obsega, časovnice, temeljnega vzroka ali vpliva.

Kontrola ISO/IEC 27002:2022 8.15 obravnava beleženje. Zenith Controls razvršča beleženje kot odkrivalno kontrolo, ki podpira zaupnost, celovitost in razpoložljivost, usklajeno s konceptom kibernetske varnosti Detect in zmogljivostjo upravljanja dogodkov informacijske varnosti. Beleženje neposredno povezuje z dejavnostmi spremljanja, oceno dogodkov, odzivom na incidente, pridobljenimi izkušnjami, privilegiranim dostopom, sinhronizacijo časa, nadzorom dostopa, zasebnostjo, zbiranjem dokazov, upravljanjem ranljivosti in spremljanjem fizične varnosti.

Zato je beleženje osrednje za dokazila po NIS2, DORA in GDPR Člen 32. Poročanje o pomembnih incidentih po NIS2 Člen 23 zahteva zgodnje opozorilo v 24 urah od seznanitve, obvestilo v 72 urah in končno poročilo najpozneje en mesec po obvestilu. Poročanje o večjih incidentih, povezanih z IKT, po DORA zahteva razvrstitev, eskalacijo, komuniciranje, analizo temeljnega vzroka in končno poročanje. Odgovornost po GDPR zahteva, da organizacije dokažejo, kaj se je zgodilo z osebnimi podatki in ali so bili varnostni ukrepi ustrezni.

Clarysecova Logging and Monitoring Policy - SME Logging and Monitoring Policy - SME zagotavlja preprosto pogodbeno kontrolo za manjše organizacije, ki uporabljajo zunanje ponudnike:

»Pogodbe morajo od ponudnikov zahtevati, da dnevnike hranijo najmanj 12 mesecev in zagotovijo dostop na zahtevo.«

Za podjetniška okolja Logging and Monitoring Policy Logging and Monitoring Policy dodaja zahtevo po operativni integraciji:

»Na zahtevo mora zagotoviti podatke dnevnikov ali se integrirati s platformo SIEM/združevanja dnevnikov organizacije.«

Te klavzule rešujejo ponavljajočo se težavo pri odzivu na incidente: med preiskavo ponudnik MDR pove, da je dogodek starejši od iskalnega obdobja hrambe, da so dnevniki na voljo samo prek plačljivega forenzičnega izvoza ali da naročnikov SIEM ne vsebuje obogatitev ponudnika in dejanj analitikov. Če dostop do dnevnikov ni vnaprej opredeljen, se časovnica incidenta razdrobi.

Močan model beleženja MDR mora opredeliti obvezne vire dnevnikov, vrste dogodkov, roke hrambe, zaščito celovitosti, odobritve dostopa, sinhronizacijo časa, izvozne formate in pravila korelacije med platformami naročnika in ponudnika. Zajemati mora tudi dejanja ponudnika, vključno s spremembami pravil zaznavanja, ukazi za izolacijo končnih točk, administratorskim dostopom, opombami analitikov in izvozi dokazil.

Podporni standardi ISO ta pristop krepijo. ISO/IEC 27035-1:2023 in ISO/IEC 27035-2:2023 povezujejo beleženje z zaznavanjem incidentov, triažo in centralizirano analizo. ISO/IEC 27701:2021 dodaja za zasebnost specifično beleženje dejavnosti obdelave osebno določljivih podatkov. ISO/IEC 27017:2021 in ISO/IEC 27018:2020 dodajata pričakovanja glede beleženja v oblaku in beleženja osebno določljivih podatkov v oblaku, zlasti kadar ponudniki obdelujejo podatke naročnikov v javnih oblačnih okoljih. ISO/IEC 27005:2024 nezadostno beleženje obravnava kot vprašanje obravnave tveganja, ne zgolj kot vrzel v orodjih.

Odziv na incidente: MDR lahko eskalira, odločiti pa mora vodstvo

Ponudniki MDR zaznavajo in svetujejo. Odgovorna organizacija razglasi incidente, presodi regulativni vpliv, komunicira z organi in odloči, ali je potrebno obvestilo o kršitvi varstva osebnih podatkov.

Ta razlika je pomembna, ker resnost po MDR ne pomeni samodejno pomembnega incidenta po NIS2, večjega incidenta, povezanega z IKT, po DORA ali kršitve varstva osebnih podatkov po GDPR. Ponudnik lahko opozorilo označi kot »visoka resnost«, vendar mora organizacija odločiti, ali so bile prizadete kritične storitve, ali so bili osebni podatki kompromitirani, ali je treba obvestiti stranke, ali je treba obvestiti regulatorje in ali mora vodstvo odobriti zajezitveni ukrep z operativnim vplivom.

Clarysecova Incident Response Policy - SME Incident Response Policy - SME je neposredna:

»Tretje osebe morajo ravnati v skladu s podpisanimi sporazumi, ki morajo vključevati klavzule o obveščanju o kršitvah varstva osebnih podatkov in obveznosti sodelovanja pri odzivu.«

Ta klavzula je mesto, kjer se dokazila po GDPR Člen 32 srečajo z operativnim odzivom na incidente. Če ponudnik MDR opazi sum iznosa podatkov s končne točke, ki vsebuje osebne podatke, mora vedeti, kako hitro obvestiti, koga obvestiti, katera dokazila ohraniti in kako podpreti presojo upravljavca.

Clarysecov Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint določa metodo testiranja. V fazi Controls in Action, korak 19, Zenith Blueprint ekipam naroča, naj operativno preverijo beleženje in spremljanje:

»Izberite nedavni incident ali dogodek in pokažite, kako ste ga sledili z uporabo svojih dnevnikov. Če se uporabljajo funkcije celovitosti dnevnikov (npr. preverjanje zgoščene vrednosti), dokumentirajte tudi to. Potrdite, da opozarjanje deluje (npr. neuspešne prijave ali povišanja privilegijev sprožijo opozorila).«

Isti korak obravnava identiteto in privilegirani dostop:

»Za privilegirane račune preverite, da je MFA uveljavljen, da so administratorske vloge ločene (računi v slogu admin_john se uporabljajo samo za administratorska opravila) in da obstaja aktualen seznam privilegiranih uporabnikov.«

V kontekstu MDR mora seznam privilegiranih uporabnikov vključevati račune ponudnika, ne samo zaposlenih. Če ima ponudnik MDR dostop do konzole, pravice za izolacijo končnih točk, administratorske pravice EDR ali bralni dostop do občutljivih dnevnikov, ti računi sodijo v pregled.

Korak 23 Zenith Blueprint nato poda strukturo testa za incidente in dobavitelje:

»Izberite nedavni dogodek ali izvedite namizno vajo za preverjanje načrta. Zajemite in zabeležite vse odločitve, vloge in komunikacije (5.26) ter posodobite načrt s pridobljenimi izkušnjami (5.27). Potrdite, da so vzpostavljeni postopki za ohranitev forenzičnih dokazov (5.28), vključno s posnetki dnevnikov, varnostnimi kopijami in varno izolacijo prizadetih sistemov.«

Realistična namizna vaja mora vključevati ponudnika MDR. Uporabite scenarij, kot so kompromitiran privilegirani račun, izolacija končne točke, sum dostopa do poštnega predala, možna izpostavljenost podatkov o plačah in eskalacija opozorila zunaj poslovnega časa. Test mora preveriti, ali se ura ponudnika MDR začne ob zaznavi, ob obvestilu naročnika ali ob potrditvi naročnika. Ta razlika je pomembna, kadar so regulativni roki odvisni od trenutka seznanitve in točk odločanja.

V 90 minutah zgradite paket nadzora MDR za eno opozorilo

Hiter način za razkritje vrzeli je izbira enega nedavnega opozorila MDR visoke resnosti in izdelava enostranske dokazne sledi. Ta praktična vaja dobro deluje pred presojami, pregledi upravnega odbora in obnovami pogodb.

1. Začnite z zahtevkom opozorila. Zajemite časovni žig, pravilo zaznavanja, prizadeto sredstvo, uporabnika, resnost, opombe analitika MDR in eskalacijsko pot.
2. Pridobite pogodbeno klavzulo ali SLA, ki prikazuje pričakovani odzivni čas za to resnost.
3. Pridobite seznam virov dnevnikov, ki dokazuje, kateri sistemi so napajali opozorilo, na primer EDR, ponudnik identitet, požarni zid, varnostni prehod za e-pošto in dnevniki revizije v oblaku.
4. Potrdite, da se dnevniki hranijo v skladu s politiko in da je zgodovinski dogodek še vedno mogoče pridobiti.
5. Preverite, ali je analitik MDR dostopal do katerega koli okolja naročnika. Če je, zajemite imenovani račun, dokazila MFA, dnevnike sej in odobritev.
6. Dokumentirajte odločitev na strani naročnika: dogodek zaključen, incident razglašen, sprožena pravna presoja, izvedena zajezitev ali sprejeto tveganje.
7. Če so lahko vključeni osebni podatki, zabeležite analizo vlog po GDPR, lastnika presoje kršitve in ali so bile sprožene obveznosti obveščanja obdelovalca.
8. Zaključite s pridobljenimi izkušnjami: uglaševanje, nova zaznava, sprememba dostopa, posodobitev odzivnega priročnika ali težava ponudnika glede SLA.

Ta sled enega opozorila je močna, ker poveže pogodbo, beleženje, dostop, odziv na incidente, zasebnost in nadzor vodstva v eno verigo dokazil. Če je ne morete zgraditi za nedavno opozorilo, je verjetno ne boste mogli zgraditi pod regulativnim pritiskom.

Spremljanje dobaviteljev je točka, kjer večina programov MDR oslabi

Številne organizacije pred podpisom pogodbe MDR izvedejo skrbni pregled, nato pa se ustavijo. To ne zadostuje za ISO/IEC 27001:2022, NIS2, DORA ali GDPR. Storitve MDR se nenehno spreminjajo: nova pravila zaznavanja, nove ekipe analitikov, novi podobdelovalci, nove podatkovne regije, nove zmogljivosti EDR, nove integracije, novi viri obveščevalnih podatkov o grožnjah in novi modeli podpore.

Kontrola ISO/IEC 27002:2022 5.22 obravnava spremljanje, pregled in upravljanje sprememb storitev dobaviteljev. Zenith Controls pojasnjuje, da 5.22 nadgrajuje kontrole odnosov z dobavitelji in sporazumov tako, da zagotavlja stalno spremljanje in upravljanje po začetku izvajanja storitve. Povezuje se z varnostjo med motnjami, upravljanjem ranljivosti, skladnostjo, nadzorom dostopa in varnim inženiringom.

Členi 28 do 30 DORA so zato še posebej pomembni za finančne subjekte. Zahtevajo stalno spremljanje, evidence ureditev s tretjimi ponudniki IKT-storitev, razlikovanje kritičnosti, skrbni pregled, pravice do revizije in inšpekcije, pravice do odpovedi, izstopne strategije, ravni storitev, pomoč pri incidentih, sodelovanje z organi ter za kritične ali pomembne funkcije ciljne ravni storitev, testiranje ukrepov ob nepredvidenih dogodkih in sodelovanje pri penetracijskem testiranju na podlagi groženj, kjer je relevantno.

Zenith Blueprint, faza Controls in Action, korak 23, zagotavlja strukturo življenjskega cikla dobaviteljev:

»Sestavite popoln seznam trenutnih dobaviteljev in izvajalcev storitev (5.19) ter jih razvrstite glede na dostop do sistemov, podatkov ali operativnega nadzora.«

Nadaljuje:

»Za vsakega kritičnega dobavitelja ugotovite, ali uporablja podizvajalce (podobdelovalce), ki lahko dostopajo do vaših podatkov ali sistemov.«

Praktičen pregled storitve MDR je treba za kritična okolja izvajati četrtletno, za okolja z nižjim tveganjem pa vsaj letno. Dnevni red mora vključevati skladnost s SLA po resnosti, eskalirana opozorila, resnično pozitivne zaznave, lažno pozitivne zaznave, zgrešene eskalacije, stanje virov dnevnikov, spremembe privilegiranega dostopa, nove integracije, nove regije, podizvajalce, podobdelovalce, spremembe pravil zaznavanja, uspešnost podpore pri incidentih, zahtevke za dokazila, odprta tveganja, korektivne ukrepe in pripravljenost na izstop.

To ni mikroupravljanje. Je zanka zagotavljanja zaupanja, ki dokazuje, da organizacija aktivno upravlja kritičnega varnostnega dobavitelja.

Preslikava navzkrižne skladnosti: en nabor kontrol MDR, pet revizijskih pogovorov

Vrednost ISO/IEC 27001:2022 je v tem, da organizacijam zagotavlja enoten cikel ISMS za več pogovorov o skladnosti. Isti paket dokazil za nadzor MDR je mogoče preslikati na NIS2, DORA, GDPR, NIST CSF 2.0 in COBIT 2019.

NIST CSF 2.0 je uporaben za komunikacijo. Njegova funkcija GOVERN zahteva, da so pravne, regulativne, pogodbene in zasebnostne obveznosti razumljene in upravljane, da so vloge in pooblastila opredeljeni, da je tveganje kibernetske varnosti vključeno v upravljanje tveganj podjetja ter da se tveganja dobaviteljev komunicirajo in spremljajo.

COBIT 2019 je uporaben za upravljanje in zagotavljanje zaupanja. Presojevalci, usmerjeni v COBIT, se pogosto manj osredotočajo na posamezno kontrolo in bolj na to, ali cilji upravljanja, upravljanje storitev, lastništvo tveganj in spremljanje uspešnosti delujejo kot sistem.

Kako bodo presojevalci testirali nadzor nad ponudnikom MDR

Različni presojevalci uporabljajo različne poglede, vendar vsi želijo dokazila, da organizacija obvladuje razmerje.

Presojevalec ISO/IEC 27001:2022 bo začel z obsegom, zainteresiranimi stranmi, oceno tveganja, Izjavo o uporabnosti, načrtom obravnave tveganja in operativnimi dokazili. Če je MDR v obsegu, bo presojevalec pričakoval, da so zunanje zagotovljeni procesi nadzorovani v okviru ISMS. V vzorcu lahko preveri odnose z dobavitelji, sporazume z dobavitelji, spremljanje storitev dobaviteljev, beleženje, spremljanje, odziv na incidente, ravnanje z dokazili in nadzor dostopa.

Nadzornik DORA se bo osredotočil na operativno odpornost in sistemsko tveganje. Podrobno lahko pregleda oceno kritičnosti, register IKT-storitev, analizo tveganja koncentracije, izstopno strategijo, razvrstitev incidentov, pravice do revizije in dokazila, da lahko ponudnik MDR podpira regulativno poročanje.

Presojevalec GDPR ali pregledovalec zasebnosti se bo osredotočil na upravljanje razmerja upravljavec–obdelovalec. Zahteval bo DPA, skrbni pregled obdelovalca, kontrole podobdelovalcev, varovalne ukrepe za dnevnike, ki vsebujejo osebne podatke, kontrole hrambe, zapise presoje kršitve in dokazila, ki podpirajo Člen 32.

Presojevalec COBIT ali ISACA bo pregledal dokazila upravljanja: lastništvo tveganj dobaviteljev, nabavni delovni tok, zapisnike pregledov storitev, sledenje težavam SLA, korektivne ukrepe, kakovost dokazil in ali vodstvo prejema smiselne kazalnike.

Najbolj razkrivajoča revizijska zahteva je preprosta: »Pokažite mi eno opozorilo MDR od zaznave do zaprtja.« Če lahko pokažete pogodbeno pričakovanje, vir dnevnika, opozorilo, eskalacijo, odločitev, ohranitev dokazil, presojo zasebnosti, sanacijo in poročanje vodstvu, je vaš nadzor MDR zrel. Če lahko pokažete samo zahtevek dobavitelja, imate spremljanje, vendar šibko upravljanje.

Poročanje vodstvu: upravni odbor ne potrebuje zajemov paketov

NIS2 in DORA obe postavljata odgovornost na raven organov upravljanja. Upravni odbori in izvršno vodstvo ne potrebujejo surove telemetrije. Potrebujejo kazalnike nadzora MDR, relevantne za tveganja.

Uporabna četrtletna nadzorna plošča MDR vključuje:

• Kritične vire dnevnikov, vključene glede na pričakovane.
• Odstotek kritičnih sredstev, pokritih z MDR.
• Opozorila visoke resnosti po kategoriji in poslovni storitvi.
• Povprečni čas od zaznave do obvestila naročniku.
• Povprečni čas od potrditve naročnika do odločitve.
• Kršitve SLA in nerešena dejanja ponudnika.
• Status pregleda privilegiranih računov ponudnika.
• Spremembe podizvajalcev ali podobdelovalcev.
• Incidenti, ki zahtevajo pravno, regulativno ali naročniško presojo obveščanja.
• Izvedene pridobljene izkušnje.

Ta nadzorna plošča mora napajati vodstveni pregled ISMS, posodobitve obravnave tveganj in pregled dobaviteljev. Po ISO/IEC 27001:2022 mora vodstvo zagotoviti, da je ISMS usklajen s strateško usmeritvijo, da so na voljo viri, da so odgovornosti dodeljene, da komunikacija deluje in da poteka nenehno izboljševanje. Kazalniki MDR so praktičen način dokazovanja, da zunanje izvajane varnostne operacije upravlja vodstvo, ne pa da so prepuščene administratorjem orodij.

Pogoste pasti pri nadzoru MDR, ki jih je treba odpraviti pred presojami 2026

Najpogostejše vrzeli so običajne napake upravljanja.

Prvič, organizacije pozabijo, da lahko ponudniki MDR obdelujejo osebne podatke. Varnostni dnevniki se včasih obravnavajo kot »tehnični podatki«, vendar lahko vsebujejo osebne podatke in občasno občutljivo vsebino. Analiza vlog po GDPR in klavzule za obdelovalce morajo biti zaključene pred uvedbo, ne med kršitvijo.

Drugič, hramba dnevnikov se predpostavlja, namesto da bi bila pogodbeno določena. Če regulativne, forenzične ali naročniške obveznosti zahtevajo dokazila za več mesecev, morata model hrambe MDR in SIEM to podpirati. Zahteva politike za MSP glede 12-mesečne hrambe dnevnikov ponudnika je praktično izhodišče za številna okolja.

Tretjič, dostop tretjih oseb je preširok. Računi ponudnika morajo biti imenovani, zaščiteni z MFA, spremljani, pregledovani in časovno omejeni, kjer je to izvedljivo. Skupni računi in neupravljane administratorske seje ustvarjajo revizijsko tveganje in tveganje pri odzivu na incidente.

Četrtič, pragovi za incidente so nejasni. Resnost MDR ne pomeni samodejno pravnega incidenta, večjega incidenta, povezanega z IKT, po DORA, pomembnega incidenta po NIS2 ali kršitve varstva osebnih podatkov po GDPR. Odzivni priročnik mora opredeliti, kdo sprejme posamezno odločitev.

Petič, podizvajalci so nevidni. Če ponudnik MDR spremeni analitične platforme, regije podpore ali nadaljnje obdelovalce, se spremeni tudi slika tveganja naročnika. Predhodno pisno soglasje in periodični pregled sta bistvena.

Šestič, pregledi storitev se osredotočajo samo na količino zahtevkov. Zreli pregledi obravnavajo zgrešena opozorila, spremembe uglaševanja, stanje virov dnevnikov, pridobivanje dokazil, dostop ponudnika, sodelovanje pri incidentih in pogodbene obveznosti.

Naslednji koraki: pripravite svojega ponudnika MDR na presojo s Clarysec

Če je vaš ponudnik MDR že v produkciji, ne čakajte na regulatorja, presojevalca naročnika ali incident, da ugotovi, da so vaša dokazila nepopolna. Začnite z enim nedavnim opozorilom in zgradite sled. Nato razvrstite ponudnika, preglejte pogodbo, preverite beleženje, testirajte eskalacijo, potrdite klavzule za obdelovalce, preglejte dostop in načrtujte spremljanje dobavitelja.

Clarysec vam lahko pomaga to hitro operacionalizirati z uporabo:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint za fazno implementacijo, vključno s korakom 19 za beleženje, spremljanje in preverjanje dostopa ter korakom 23 za kontrole dobaviteljev in upravljanja incidentov.
• Zenith Controls: The Cross-Compliance Guide Zenith Controls za preslikavo kontrol ISO/IEC 27002:2022 5.19, 5.22 in 8.15 v revizijska pričakovanja NIS2, DORA, GDPR, NIST in COBIT.
• Predloge politik Clarysec, vključno z Incident Response Policy, Third party and supplier security policy, Logging and Monitoring Policy, Incident Response Policy - SME, Third-Party and Supplier Security Policy - SME, Logging and Monitoring Policy - SME in Data Protection and Privacy Policy - SME.

MDR je ena najvrednejših varnostnih naložb, ki jih lahko izvede organizacija. V letu 2026 mora biti ta vrednost dokazana z upravljanjem, dokazili in odgovornim nadzorom. Če želite praktičen paket nadzora MDR, preslikan na ISO/IEC 27001:2022, NIS2, DORA in GDPR Člen 32, vam lahko Clarysec pomaga, da ga zgradite, preden naslednje opozorilo postane naslednja revizijska ugotovitev.