MDR paslaugų teikėjo priežiūra pagal NIS2, DORA ir GDPR

Pirmadienio rytą, 02:13, MDR paslaugų teikėjas atidaro didelio kritiškumo perspėjimą: neįmanoma kelionė, įtartinos pašto dėžutės taisyklės ir privilegijuotoji paskyra, naudota iš nevaldomo galinio įrenginio. SOC analitikas eskaluoja įvykį per užklausų portalą. Jūsų IT vadovas miega. Finansų direktorius iš banko kontakto gauna įspėjimą apie fišingą anksčiau, nei pabunda vidinis incidentų kanalas. 07:30 CISO jau turi atsakyti į tris nepatogius klausimus.

Kas turėjo įgaliojimus paskelbti incidentą?

Ar galime įrodyti, kad MDR paslaugų teikėjas turėjo tinkamus žurnalus, juos saugojo pakankamai ilgai ir išsaugojo įrodymus?

Jeigu buvo pasiekti asmens duomenys, ar Teisės padalinys gali įvykdyti GDPR pažeidimo vertinimo terminus, kol operacijų komanda rengia NIS2 arba DORA pranešimą?

Po mėnesio išorės auditorius paprašo tų pačių įrodymų, tik kitu tonu. MDR paslaugų teikėjo PDF ataskaita naudinga, bet jos nepakanka. Auditorius nori pirminių perspėjimo duomenų, pilnų žurnalų failų, eskalavimo pėdsako, vidinio sprendimų žurnalo, tiekėjo peržiūros įrašo ir įrodymo, kad organizacija galėjo savarankiškai patikrinti, kas įvyko.

Tai ir yra 2026 m. MDR paslaugų teikėjo priežiūros problema. Organizacijos perduoda aptikimą ir reagavimą išorės paslaugų teikėjams, nes vidinio SOC pajėgumai brangūs, darbuotojus sunku pritraukti, o grėsmių aktyvumas nemažėja. Tačiau išorinis aptikimas nereiškia išorinės atskaitomybės. Pagal NIS2 valdymo organai išlieka atsakingi už kibernetinio saugumo rizikos valdymo priemonių patvirtinimą ir priežiūrą. Pagal DORA finansų subjektai išlieka visiškai atsakingi už IRT trečiųjų šalių riziką, įskaitant kritines IRT paslaugas, incidentų palaikymą, audito teises, subtiekimą ir pasitraukimą. Pagal GDPR duomenų valdytojai turi įrodyti tinkamą tvarkymo saugumą, ypač kai duomenų tvarkytojai tvarko telemetriją, galinių įrenginių duomenis, naudotojų identifikatorius, IP adresus, el. pašto turinį, žurnalus arba skaitmeninės kriminalistikos atvaizdus.

Praktinė spraga retai būna vien MDR sutartyje. Ji slypi įrodymų grandinėje tarp sutarties ir veikiančios paslaugos: perspėjimų nukreipime, privilegijuotojoje prieigoje, žurnalų saugojime, eskalavimo slenksčiuose, incidentų įrodymuose, subtiekėjų skaidrume, duomenų tvarkytojo nuostatose, paslaugų peržiūrose, stalo pratybose ir vadovybei teikiamose ataskaitose.

Pagrįstai MDR paslaugų teikėjo priežiūros programai reikia vieno veiklos modelio, kuris atlaikytų kelias audito diskusijas. ISO/IEC 27001:2022 suteikia tam pagrindą.

MDR priežiūra prasideda nuo atskaitomybės, o ne nuo SOC konsolės

Dažna klaida – MDR paleidimą vertinti kaip techninį projektą: įdiegti EDR agentus, persiųsti tapatybės žurnalus, sukonfigūruoti perspėjimus, sutarti dėl Teams ar Slack kanalo ir paleisti paslaugą. Tai gali pagerinti aptikimą, tačiau neįrodo valdysenos.

NIS2 šį klausimą įvardija aiškiai. Esminiai ir svarbūs subjektai turi įgyvendinti tinkamas ir proporcingas technines, operacines ir organizacines kibernetinio saugumo rizikos valdymo priemones. Article 21 apima rizikos analizę, incidentų valdymą, veiklos tęstinumą, tiekimo grandinės saugumą, kibernetinę higieną, prieigos kontrolę, turto valdymą, kriptografiją ir daugiaveiksnį autentifikavimą. Article 20 šį klausimą pakelia iki valdymo organo atskaitomybės, reikalaudamas šių priemonių patvirtinimo ir priežiūros.

MDR paslaugų teikėjai dažnai vienu metu patenka į kelias NIS2 Article 21 sritis:

• Incidentų valdymas, nes paslaugų teikėjas atlieka triažą, eskaluoja ir gali rekomenduoti lokalizavimą.
• Tiekimo grandinės saugumas, nes paslaugų teikėjas yra tiesioginis paslaugų teikėjas, turintis poveikį operaciniam saugumui.
• Prieigos kontrolė, nes paslaugų teikėjas gali pasiekti konsoles, žurnalus, galinių įrenginių priemones arba debesijos nuomininkus.
• Žurnalų tvarkymas ir stebėsena, nes aptikimas priklauso nuo žurnalų aprėpties, saugojimo ir koreliacijos.
• Kibernetinė higiena, nes MDR išvados dažnai atskleidžia pataisų diegimo, tapatybės arba konfigūracijos trūkumus.
• Veiklos tęstinumas, nes pavėluotas reagavimas gali sutrikdyti kritines paslaugas.

Finansų subjektams DORA sustiprina veiklos modelį. DORA taikomas nuo 2025 m. sausio 17 d. ir reikalauja IRT rizikos valdymo, pranešimo apie incidentus, atsparumo testavimo, dalijimosi informacija ir IRT trečiųjų šalių rizikos valdymo. Jame taip pat paaiškinama, kad finansų subjektams, kurie taip pat identifikuojami pagal NIS2, DORA veikia kaip sektorinis Sąjungos teisės aktas dėl persidengiančių kibernetinio saugumo pareigų. Reguliuojamas bankas, mokėjimo įstaiga, investicinė įmonė, draudikas ar kriptoturto paslaugų teikėjas negali tiesiog pasakyti: „Tuo pasirūpina mūsų MDR paslaugų teikėjas.“ DORA tikisi, kad subjektas klasifikuos IRT incidentus, valdys ir stebės IRT trečiųjų šalių paslaugų teikėjus, tvarkys IRT paslaugų susitarimų registrus, apibrėš sutartines teises, testuos atsparumą, atliks pagrindinės priežasties analizę ir etapais praneš apie reikšmingus su IRT susijusius incidentus.

GDPR prideda kitą perspektyvą. Jeigu MDR telemetrija apima naudotojų identifikatorius, IP adresus, el. pašto metaduomenis, autentifikavimo įrašus, galinių įrenginių artefaktus arba failus su asmens duomenimis, taikomi GDPR saugumo ir atskaitomybės principai. Article 5 apima vientisumą, konfidencialumą ir atskaitomybę. Article 32 tvarkymo saugumas tampa praktiniu įrodymų klausimu: ar žurnalai buvo apsaugoti, ar prieiga buvo apribota, ar šifravimas taikytas ten, kur tinkama, ar duomenų tvarkytojai buvo valdomi, ir ar organizacija gali įrodyti, kas įvyko.

Žinutė visuose trijuose režimuose vienoda: darbą galite deleguoti, bet atsakomybės – ne.

ISO/IEC 27001:2022 paverčia MDR audituojamu procesu

Tinkamai įgyvendinta ISO/IEC 27001:2022 pagrįsta ISVS paverčia MDR paslaugų teikėjo priežiūrą iš tiekėjų valdymo pažado į įrodymais pagrįstą veiklos modelį. Clause 8.1 ypač svarbi, nes reikalauja, kad organizacijos kontroliuotų išorės teikiamus procesus, produktus ir paslaugas, svarbius ISVS. MDR yra būtent tai: išorės teikiamas procesas, galintis paveikti reagavimą į incidentus, privatumą, atsparumą, pranešimą reguliuotojui ir veiklos tęstinumą.

Svarbiausios ISO/IEC 27001:2022 Annex A sritys MDR priežiūrai apima tiekėjų santykius, saugumo reikalavimus tiekėjų susitarimuose, IRT tiekimo grandinės rizikos valdymą, tiekėjo paslaugų stebėseną, incidentų valdymą, įrodymų tvarkymą, žurnalų tvarkymą, stebėseną, prieigos kontrolę, privilegijuotąją prieigą, kriptografiją ir pasirengimą veiklos tęstinumui.

Clarysec Zenith Controls: The Cross-Compliance Guide Zenith Controls yra šio darbo kryžminės atitikties atskaitos šaltinis. Jis susieja ISO/IEC 27002:2022 kontrolės priemones su kitais reikalavimais, susijusiomis kontrolės priemonėmis, audito lūkesčiais ir įgyvendinimo įrodymais. MDR priežiūrai svarbiausios trys ISO/IEC 27002:2022 kontrolės priemonės: 5.19 tiekėjų santykiams, 5.22 tiekėjo paslaugų stebėsenai ir pakeitimų valdymui ir 8.15 žurnalų tvarkymui. Jas palaiko 5.20 tiekėjų susitarimai, 5.21 IRT tiekimo grandinės saugumas, 5.24 to 5.28 incidentų valdymas ir įrodymų tvarkymas, 5.34 privatumas ir PII, 5.36 atitiktis, 8.16 stebėsenos veiklos, 8.17 laikrodžių sinchronizavimas, 8.18 privilegijuotų paslaugų programų naudojimas ir 8.8 techninių pažeidžiamumų valdymas.

Tai svarbu, nes MDR audito nesėkmė retai reiškia „nėra MDR“. Dažniausiai ji reiškia vieną iš šių dalykų:

• MDR paslaugų teikėjas nebuvo klasifikuotas kaip kritinis.
• Sutartinės nuostatos neapėmė pranešimo apie incidentus, prieigos prie įrodymų arba audito teisių.
• Žurnalai nebuvo saugomi pakankamai ilgai, kad būtų galima ištirti praneštą įvykį.
• Paslaugų teikėjo prieiga buvo bendra, nuolatinė arba nestebima.
• Klientas neperžiūrėjo MDR veikimo pagal SLA.
• Subtiekėjai arba subtvarkytojai nebuvo patvirtinti.
• Pranešimo apie asmens duomenų saugumo pažeidimą pareigos nebuvo suderintos su incidentų darbo eiga.
• Įrodymai nebuvo išsaugoti skaitmeninei kriminalistikai tinkamu būdu.
• Vadovybė neturėjo rodiklių, rodančių, ar MDR paslauga sumažino riziką.

Zenith Controls aiškiai nusako tiekėjų lūkesčių ir susitarimų ryšį:

„5.19 nustato saugumo lūkesčius, kaip tiekėjai turi tvarkyti organizacijos informaciją. 5.20 formalizuoja šiuos lūkesčius užtikrindama, kad sutartyse ar susitarimuose būtų aiškiai įtrauktos saugumo nuostatos, tokios kaip konfidencialumo reikalavimai, saugumo politikų laikymasis ir pranešimo apie incidentus procedūros. Be 5.20 reikalavimai, identifikuoti pagal 5.19, gali būti teisiškai neįgyvendinami.“

MDR atveju šis sakinys yra valdysenos pamoka. Jeigu sutartis nereikalauja, kad paslaugų teikėjas saugotų žurnalus, teiktų įrodymus, bendradarbiautų incidentų metu, ribotų subtiekimą, palaikytų auditus ir laikytųsi eskalavimo terminų, SOC paslauga gali būti naudinga operaciniu požiūriu, bet silpna audito požiūriu.

Ką MDR sutartis turi įrodyti iki pirmojo perspėjimo

Gera MDR sutartis nėra vien komercinis užsakymo dokumentas. Tai kontrolės dokumentas. DORA Articles 28 to 30 reikalauja, kad IRT trečiųjų šalių rizika būtų valdoma per visą gyvavimo ciklą, įskaitant IRT sutarčių registrus, kritiškumo klasifikavimą, ikisutartinį deramą patikrinimą, audito ir patikrinimų metodus, nutraukimo teises, pasitraukimo strategijas, aiškius paslaugų aprašymus, paslaugų lygius, paslaugos ir duomenų tvarkymo vietas, duomenų apsaugos įsipareigojimus, pagalbą incidentų metu ir bendradarbiavimą su institucijomis. NIS2 Article 21 reikalauja tiekimo grandinės saugumo tiesioginiams tiekėjams ir paslaugų teikėjams. GDPR reikalauja duomenų valdytojo ir duomenų tvarkytojo vaidmenų, duomenų tvarkytojo garantijų, duomenų apsaugos nuostatų ir tvarkymo saugumo įrodymų.

Clarysec politikų biblioteka šias pareigas paverčia praktiniais sutartiniais ir veiklos reikalavimais. Enterprise Incident Response Policy Incident Response Policy MDR aiškiai traktuoja kaip valdomą trečiosios šalies incidentų valdymo pajėgumą:

„Integracija su trečiųjų šalių paslaugomis, įskaitant Managed Detection and Response (MDR), Security Incident and Event Management (SIEM) ir skaitmeninės kriminalistikos paslaugų teikėjus, turi būti valdoma aiškiai apibrėžtais paslaugų lygio susitarimais (SLA) ir konfidencialumo nuostatomis.“

Ši nuostata svarbi, nes MDR paslaugų teikėjai dažnai gauna itin jautrią informaciją dar prieš organizacijai žinant, ar incidentas yra praneštinas. Telemetrija gali apimti naudotojų vardus, failų kelius, el. laiškų temas, vidinius kompiuterių vardus, IP adresus, tinklo schemas ir kompromitavimo indikatorius. Konfidencialumo nuostatos saugo organizaciją tyrimo metu ir palaiko GDPR atskaitomybę.

Enterprise Third party and supplier security policy Third party and supplier security policy prideda dvi nuostatas, kurias auditoriai tikisi matyti peržiūrėdami MDR priežiūrą:

„Teisės atlikti auditą, tikrinti ir prašyti saugumo įrodymų“

ir:

„Subtiekėjų naudojimas tik gavus išankstinį rašytinį sutikimą“

MVĮ atveju tas pats valdysenos principas supaprastinamas, bet nepanaikinamas. Third-Party and Supplier Security Policy - SME Third-Party and Supplier Security Policy - SME reikalauja mažiausių privilegijų principo:

„Tiekėjams turi būti suteikiama prieiga tik prie minimalių sistemų ir duomenų, būtinų jų funkcijai atlikti.“

Ji taip pat reikalauja:

„Papildomo subtiekimo apribojimų be patvirtinimo“

Šios nuostatos ypač aktualios MDR. Daugelis paslaugų teikėjų naudoja kelių lygių SOC komandas, platformų tiekėjus, grėsmių žvalgybos partnerius, debesijos analizės paslaugas arba regioninius pagalbos darbuotojus. Jeigu žemiau grandinėje esančios šalys gali pasiekti kliento žurnalus arba asmens duomenis, klientui reikia matomumo ir patvirtinimo mechanizmų. DORA požiūriu tai yra subtiekimo ir koncentracijos rizikos priežiūros dalis. GDPR požiūriu tai yra subtvarkytojų valdysena. NIS2 požiūriu tai yra tiekimo grandinės rizikos valdymas.

Esminis MDR priežiūros kontrolinis sąrašas

Pagrįsti MDR paslaugų teikėjo santykiai turi būti testuojami. Toliau pateiktas kontrolinis sąrašas sutartinius, operacinius ir įrodymų reikalavimus sujungia į vieną kontrolės vaizdą.

Šis kontrolinis sąrašas turi būti įtrauktas į pirkimus, paslaugos paleidimą, periodinę peržiūrą ir incidentų testavimą. Jei trūksta bent vieno punkto, organizacija tai turi vertinti kaip tiekėjų riziką, o ne kaip dokumentacijos trūkumą.

Septynios įrodymų sritys, kurių tikisi auditoriai

Kad MDR priežiūra būtų tinkama auditui, Clarysec rekomenduoja sukurti MDR įrodymų bylą, suskirstytą į septynias sritis. Ši byla turi būti ISVS dalis, o ne pirkimų aplankas, kurio niekas neperžiūri.

Ši lentelė pakeičia pokalbį su paslaugų teikėju. Užuot klaususi „Ar jūs mus stebite?“, organizacija klausia: „Ar galime kas ketvirtį įrodyti, kad MDR paslauga išlieka veiksminga, atitinkanti reikalavimus ir suderinta su mūsų rizikos apetitu?“

Žurnalų tvarkymas yra tiltas tarp aptikimo ir atitikties įrodymų

MDR be patikimo žurnalų tvarkymo yra išorės paslaugų teikėjui perduotas spėjimas. Paslaugų teikėjas gali aptikti kai kurias grėsmes, tačiau organizacija negali įrodyti apimties, laiko juostos, pagrindinės priežasties ar poveikio.

ISO/IEC 27002:2022 kontrolė 8.15 apima žurnalų tvarkymą. Zenith Controls žurnalų tvarkymą klasifikuoja kaip nustatomąją kontrolės priemonę, palaikančią konfidencialumą, vientisumą ir prieinamumą, suderintą su aptikimo kibernetinio saugumo koncepcija ir informacijos saugumo įvykių valdymo pajėgumu. Jis tiesiogiai susieja žurnalų tvarkymą su stebėsenos veiklomis, įvykių vertinimu, reagavimu į incidentus, įgyta patirtimi, privilegijuotąja prieiga, laikrodžių sinchronizavimu, prieigos kontrole, privatumu, įrodymų rinkimu, pažeidžiamumų valdymu ir fizinio saugumo stebėsena.

Todėl žurnalų tvarkymas yra esminis NIS2, DORA ir GDPR Article 32 įrodymams. NIS2 Article 23 pranešimas apie reikšmingus incidentus reikalauja ankstyvo įspėjimo per 24 valandas nuo sužinojimo, pranešimo per 72 valandas ir galutinės ataskaitos ne vėliau kaip per vieną mėnesį po pranešimo. DORA pranešimas apie reikšmingus su IRT susijusius incidentus reikalauja klasifikavimo, eskalavimo, komunikacijos, pagrindinės priežasties analizės ir galutinio pranešimo. GDPR atskaitomybė reikalauja, kad organizacijos įrodytų, kas įvyko su asmens duomenimis ir ar saugumo priemonės buvo tinkamos.

Clarysec Logging and Monitoring Policy - SME Logging and Monitoring Policy - SME mažesnėms organizacijoms, naudojančioms išorės paslaugų teikėjus, pateikia paprastą sutartinę kontrolės priemonę:

„Sutartys turi reikalauti, kad paslaugų teikėjai saugotų žurnalus bent 12 mėnesių ir suteiktų prieigą pagal prašymą“

Įmonių aplinkoms Logging and Monitoring Policy Logging and Monitoring Policy prideda operacinės integracijos reikalavimą:

„Privaloma pateikti žurnalų duomenis pagal prašymą arba integruotis su organizacijos SIEM / žurnalų agregavimo platforma.“

Šios nuostatos sprendžia pasikartojančią reagavimo į incidentus problemą: tyrimo metu MDR paslaugų teikėjas teigia, kad įvykis senesnis nei paieškai prieinamas saugojimo langas, žurnalai prieinami tik per mokamą skaitmeninės kriminalistikos eksportą arba kliento SIEM neturi paslaugų teikėjo praturtintų duomenų ir analitiko veiksmų. Jeigu prieiga prie žurnalų nėra apibrėžta iš anksto, incidento laiko juosta susiskaido.

Stiprus MDR žurnalų tvarkymo modelis turi apibrėžti privalomus žurnalų šaltinius, įvykių tipus, saugojimo terminus, vientisumo apsaugą, prieigos patvirtinimus, laiko sinchronizavimą, eksporto formatus ir koreliacijos taisykles tarp kliento ir paslaugų teikėjo platformų. Jis taip pat turi apimti paslaugų teikėjo veiksmus, įskaitant aptikimo taisyklių pakeitimus, galinių įrenginių izoliavimo komandas, administratoriaus lygmens prieigą, analitiko pastabas ir įrodymų eksportą.

ISO pagalbiniai standartai sustiprina šį požiūrį. ISO/IEC 27035-1:2023 ir ISO/IEC 27035-2:2023 susieja žurnalų tvarkymą su incidentų aptikimu, triažu ir centralizuota analize. ISO/IEC 27701:2021 prideda privatumui skirtą PII tvarkymo veiklų žurnalų tvarkymą. ISO/IEC 27017:2021 ir ISO/IEC 27018:2020 prideda debesijos ir debesijoje tvarkomų PII žurnalų tvarkymo lūkesčius, ypač kai paslaugų teikėjai tvarko kliento duomenis viešosios debesijos aplinkose. ISO/IEC 27005:2024 nepakankamą žurnalų tvarkymą vertina kaip rizikos tvarkymo klausimą, o ne vien įrankių spragą.

Reagavimas į incidentus: MDR gali eskaluoti, bet sprendimą turi priimti vadovybė

MDR paslaugų teikėjai aptinka ir pataria. Atskaitinga organizacija paskelbia incidentus, vertina reglamentavimo poveikį, bendrauja su institucijomis ir sprendžia, ar reikia pranešti apie asmens duomenų saugumo pažeidimą.

Šis skirtumas svarbus, nes MDR kritiškumas automatiškai nereiškia NIS2 reikšmingo incidento, DORA reikšmingo su IRT susijusio incidento ar GDPR asmens duomenų saugumo pažeidimo. Paslaugų teikėjas perspėjimą gali pažymėti kaip „didelio kritiškumo“, tačiau organizacija turi nuspręsti, ar buvo paveiktos kritinės paslaugos, ar buvo kompromituoti asmens duomenys, ar reikia informuoti klientus, ar reikia pranešti reguliuotojams ir ar vadovybė turi patvirtinti lokalizavimo veiksmą, turintį operacinį poveikį.

Clarysec Incident Response Policy - SME Incident Response Policy - SME yra tiesioginė:

„Trečiosios šalys turi veikti pagal pasirašytus susitarimus, kuriuose turi būti asmens duomenų saugumo pažeidimo pranešimo nuostatos ir bendradarbiavimo reagavimo metu pareigos.“

Ši nuostata yra vieta, kur GDPR Article 32 įrodymai susitinka su operaciniu reagavimu į incidentus. Jeigu MDR paslaugų teikėjas pastebi įtariamą duomenų iškėlimą iš galinio įrenginio, kuriame yra asmens duomenų, paslaugų teikėjas turi žinoti, kaip greitai pranešti, kam pranešti, kokius įrodymus išsaugoti ir kaip padėti duomenų valdytojo vertinimui.

Clarysec Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint pateikia testavimo metodą. Controls in Action fazėje, Step 19, Zenith Blueprint nurodo komandoms operaciškai validuoti žurnalų tvarkymą ir stebėseną:

„Pasirinkite neseną incidentą ar įvykį ir parodykite, kaip jį atsekėte naudodami savo žurnalus. Jei naudojamos žurnalų vientisumo funkcijos (pvz., maišos reikšmės patikrinimas), tai taip pat dokumentuokite. Patvirtinkite, kad perspėjimai veikia (pvz., nesėkmingi prisijungimai ar privilegijų pakėlimai sukelia perspėjimus).“

Tas pats žingsnis aptaria tapatybę ir privilegijuotąją prieigą:

„Privilegijuotoms paskyroms patikrinkite, ar taikomas MFA, ar administratoriaus vaidmenys atskirti (admin_john tipo paskyros naudojamos tik administratoriaus užduotims) ir ar yra aktualus privilegijuotų naudotojų sąrašas.“

MDR kontekste privilegijuotų naudotojų sąrašas turi apimti paslaugų teikėjo paskyras, ne tik darbuotojus. Jeigu MDR paslaugų teikėjas turi prieigą prie konsolės, galinių įrenginių izoliavimo teises, EDR administravimo teises arba skaitymo prieigą prie jautrių žurnalų, šios paskyros turi būti įtrauktos į peržiūrą.

Zenith Blueprint Step 23 pateikia incidentų ir tiekėjų testavimo struktūrą:

„Pasirinkite neseną įvykį arba atlikite stalo pratybas planui validuoti. Užfiksuokite ir užregistruokite visus sprendimus, vaidmenis ir komunikaciją (5.26), o planą atnaujinkite pagal įgytą patirtį (5.27). Patvirtinkite, kad yra procedūros skaitmeninės kriminalistikos įrodymams išsaugoti (5.28), įskaitant žurnalų momentines kopijas, atsargines kopijas ir saugų paveiktų sistemų izoliavimą.“

Realistiškose stalo pratybose turi dalyvauti MDR paslaugų teikėjas. Naudokite scenarijų, pavyzdžiui, kompromituota privilegijuotoji paskyra, galinio įrenginio izoliavimas, įtariama pašto dėžutės prieiga, galimas darbo užmokesčio duomenų atskleidimas ir perspėjimo eskalavimas ne darbo valandomis. Testas turi patikrinti, ar MDR paslaugų teikėjo laikas pradedamas skaičiuoti nuo aptikimo, kliento informavimo ar kliento patvirtinimo. Šis skirtumas svarbus, kai reglamentavimo terminai priklauso nuo sužinojimo ir sprendimo momentų.

Sukurkite vieno perspėjimo MDR priežiūros paketą per 90 minučių

Greitas būdas atskleisti spragas – pasirinkti vieną neseną didelio kritiškumo MDR perspėjimą ir sukurti vieno puslapio įrodymų pėdsaką. Ši praktinė užduotis gerai veikia prieš auditus, valdybos peržiūras ir sutarčių atnaujinimą.

1. Pradėkite nuo perspėjimo užklausos. Užfiksuokite laiko žymą, aptikimo taisyklę, paveiktą turtą, naudotoją, kritiškumą, MDR analitiko pastabas ir eskalavimo kelią.
2. Paimkite sutarties nuostatą arba SLA, rodantį numatomą reagavimo laiką šiam kritiškumo lygiui.
3. Gaukite žurnalų šaltinių sąrašą, įrodantį, kurios sistemos teikė duomenis perspėjimui, pvz., EDR, tapatybės teikėjas, ugniasienė, el. pašto saugumo šliuzas ir debesijos audito žurnalai.
4. Patvirtinkite, kad žurnalai saugomi pagal politiką ir kad istorinį įvykį vis dar galima gauti.
5. Patikrinkite, ar MDR analitikas pasiekė bet kurią kliento aplinką. Jei taip, užfiksuokite vardinę paskyrą, MFA įrodymus, sesijos žurnalus ir patvirtinimą.
6. Dokumentuokite kliento pusės sprendimą: įvykis uždarytas, incidentas paskelbtas, inicijuotas teisinis vertinimas, atliktas lokalizavimas arba rizika priimta.
7. Jei gali būti susiję asmens duomenys, užfiksuokite GDPR vaidmenų analizę, pažeidimo vertinimo savininką ir ar buvo aktyvuotos duomenų tvarkytojo pranešimo pareigos.
8. Užbaikite įgyta patirtimi: derinimas, naujas aptikimas, prieigos pakeitimas, reagavimo veiksmų plano atnaujinimas arba tiekėjo SLA problema.

Šis vieno perspėjimo pėdsakas veiksmingas, nes vienoje įrodymų grandinėje sujungia sutartį, žurnalų tvarkymą, prieigą, reagavimą į incidentus, privatumą ir vadovybės priežiūrą. Jei negalite jo sukurti nesenam perspėjimui, tikėtina, kad negalėsite jo sukurti ir patirdami reglamentavimo spaudimą.

Tiekėjų stebėsena yra vieta, kur dauguma MDR programų silpnėja

Daugelis organizacijų prieš pasirašydamos MDR sutartį atlieka deramą patikrinimą ir tuo sustoja. To nepakanka ISO/IEC 27001:2022, NIS2, DORA ar GDPR atžvilgiu. MDR paslaugos nuolat keičiasi: naujos aptikimo taisyklės, naujos analitikų komandos, nauji subtvarkytojai, nauji duomenų regionai, naujos EDR galimybės, naujos integracijos, nauji grėsmių žvalgybos srautai ir nauji pagalbos modeliai.

ISO/IEC 27002:2022 kontrolė 5.22 apima tiekėjo paslaugų stebėseną, peržiūrą ir pakeitimų valdymą. Zenith Controls paaiškina, kad 5.22 remiasi tiekėjų santykių ir susitarimų kontrolės priemonėmis, užtikrindama nuolatinę stebėseną ir valdymą po paslaugos pradžios. Ji susijusi su saugumu trikdžių metu, pažeidžiamumų valdymu, atitiktimi, prieigos kontrole ir saugia inžinerija.

DORA Articles 28 to 30 daro tai ypač svarbu finansų subjektams. Jie reikalauja nuolatinės stebėsenos, IRT trečiųjų šalių susitarimų registrų, kritiškumo atskyrimo, deramo patikrinimo, audito ir patikrinimo teisių, nutraukimo teisių, pasitraukimo strategijų, paslaugų lygių, pagalbos incidentų metu, bendradarbiavimo su institucijomis ir, kritinėms ar svarbioms funkcijoms, paslaugų tikslų, nenumatytų atvejų testavimo ir bendradarbiavimo atliekant grėsmėmis grindžiamą įsiskverbimo testavimą, kai taikoma.

Zenith Blueprint, Controls in Action fazės Step 23, pateikia tiekėjo gyvavimo ciklo struktūrą:

„Sudarykite pilną esamų tiekėjų ir paslaugų teikėjų sąrašą (5.19) ir klasifikuokite juos pagal prieigą prie sistemų, duomenų arba operacinės kontrolės.“

Toliau nurodoma:

„Kiekvienam kritiniam tiekėjui nustatykite, ar jis naudoja subtiekėjus (subtvarkytojus), kurie gali pasiekti jūsų duomenis ar sistemas.“

Praktinė MDR paslaugos peržiūra kritinėms aplinkoms turi būti rengiama kas ketvirtį, o mažesnės rizikos aplinkoms – bent kartą per metus. Darbotvarkė turi apimti SLA laikymąsi pagal kritiškumą, eskaluotus perspėjimus, tikrai teigiamus atvejus, klaidingai teigiamus atvejus, praleistus eskalavimus, žurnalų šaltinių būklę, privilegijuotosios prieigos pakeitimus, naujas integracijas, naujus regionus, subtiekėjus, subtvarkytojus, aptikimo taisyklių pakeitimus, incidentų palaikymo veikimą, įrodymų prašymus, atviras rizikas, korekcinius veiksmus ir pasirengimą pasitraukimui.

Tai nėra mikrovadyba. Tai patikinimo ciklas, įrodantis, kad organizacija aktyviai valdo kritinį saugumo tiekėją.

Kryžminės atitikties susiejimas: vienas MDR kontrolės priemonių rinkinys, penkios audito diskusijos

ISO/IEC 27001:2022 vertė yra ta, kad jis suteikia organizacijoms vieną nuoseklų ISVS ciklą kelioms atitikties diskusijoms. Tas pats MDR priežiūros įrodymų paketas gali būti susietas su NIS2, DORA, GDPR, NIST CSF 2.0 ir COBIT 2019.

NIST CSF 2.0 naudinga komunikacijai. Jo GOVERN funkcija reikalauja, kad teisinės, reglamentavimo, sutartinės ir privatumo pareigos būtų suprastos ir valdomos, vaidmenys ir įgaliojimai būtų apibrėžti, kibernetinio saugumo rizika būtų integruota į įmonės rizikos valdymą, o tiekėjų rizikos būtų komunikuojamos ir stebimos.

COBIT 2019 naudinga vadybai ir patikinimui. COBIT orientuoti auditoriai dažnai mažiau dėmesio skiria vienai kontrolės priemonei ir daugiau – ar valdysenos tikslai, paslaugų valdymas, rizikos savininkystė ir veiklos stebėsena veikia kaip sistema.

Kaip auditoriai testuos MDR paslaugų teikėjo priežiūrą

Skirtingi auditoriai taiko skirtingas perspektyvas, tačiau visi nori įrodymų, kad organizacija kontroliuoja santykius.

ISO/IEC 27001:2022 auditorius pradės nuo taikymo srities, suinteresuotųjų šalių, rizikos vertinimo, Taikytinumo pareiškimo, Rizikos tvarkymo plano ir operacinių įrodymų. Jeigu MDR patenka į taikymo sritį, auditorius tikėsis, kad išorės teikiami procesai bus kontroliuojami pagal ISVS. Jis gali atrinkti tiekėjų santykių, tiekėjų susitarimų, tiekėjo paslaugų stebėsenos, žurnalų tvarkymo, stebėsenos, reagavimo į incidentus, įrodymų tvarkymo ir prieigos kontrolės pavyzdžius.

DORA priežiūros institucija daugiausia dėmesio skirs operaciniam atsparumui ir sisteminei rizikai. Ji gali išsamiai vertinti kritiškumo vertinimą, IRT paslaugų registrą, koncentracijos rizikos analizę, pasitraukimo strategiją, incidentų klasifikavimą, audito teises ir įrodymus, kad MDR paslaugų teikėjas gali padėti teikti reglamentavimo pranešimus.

GDPR auditorius arba privatumo peržiūrą atliekantis specialistas dėmesį sutelks į duomenų valdytojo ir duomenų tvarkytojo valdyseną. Jis paprašys duomenų tvarkymo sutarties, duomenų tvarkytojo deramo patikrinimo, subtvarkytojų kontrolės priemonių, apsaugos priemonių žurnalams su asmens duomenimis, saugojimo kontrolės priemonių, pažeidimo vertinimo įrašų ir Article 32 pagrindžiančių įrodymų.

COBIT arba ISACA auditorius tikrins valdysenos įrodymus: tiekėjų rizikos savininkystę, pirkimų darbo eigą, paslaugų peržiūros protokolus, SLA problemų sekimą, korekcinius veiksmus, įrodymų kokybę ir ar vadovybė gauna prasmingus rodiklius.

Labiausiai atskleidžiantis audito prašymas yra paprastas: „Parodykite vieną MDR perspėjimą nuo aptikimo iki uždarymo.“ Jei galite parodyti sutartinį lūkestį, žurnalų šaltinį, perspėjimą, eskalavimą, sprendimą, įrodymų išsaugojimą, privatumo vertinimą, taisomuosius veiksmus ir vadovybės ataskaitą, jūsų MDR priežiūra yra brandi. Jei galite parodyti tik tiekėjo užklausą, turite stebėseną, bet silpną valdyseną.

Ataskaitos vadovybei: valdybai nereikia paketų įrašų

NIS2 ir DORA atsakomybę priskiria valdymo organo lygiui. Valdyboms ir vykdomiesiems vadovams nereikia pirminės telemetrijos. Jiems reikia su rizika susijusių MDR priežiūros rodiklių.

Naudinga ketvirtinė MDR suvestinė apima:

• Įtrauktus kritinius žurnalų šaltinius, palyginti su numatytais.
• Kritinio turto, kuriam taikoma MDR aprėptis, procentinę dalį.
• Didelio kritiškumo perspėjimus pagal kategoriją ir verslo paslaugą.
• Vidutinį laiką nuo aptikimo iki kliento informavimo.
• Vidutinį laiką nuo kliento patvirtinimo iki sprendimo.
• SLA pažeidimus ir neišspręstus paslaugų teikėjo veiksmus.
• Privilegijuotų paslaugų teikėjo paskyrų peržiūros būseną.
• Subtiekėjų arba subtvarkytojų pakeitimus.
• Incidentus, kuriems reikalingas teisinis, reglamentavimo arba klientų informavimo vertinimas.
• Įgyvendintą įgytą patirtį.

Ši suvestinė turi būti naudojama ISVS vadovybės peržiūrai, rizikos tvarkymo atnaujinimams ir tiekėjo peržiūrai. Pagal ISO/IEC 27001:2022 vadovybė turi užtikrinti, kad ISVS būtų suderinta su strategine kryptimi, ištekliai būtų prieinami, atsakomybės priskirtos, komunikacija veiktų ir vyktų nuolatinis tobulinimas. MDR rodikliai yra praktinis būdas parodyti, kad išorės saugumo operacijas valdo vadovybė, o ne jos paliekamos įrankių administratoriams.

Dažnos MDR priežiūros spragos, kurias reikia pašalinti iki 2026 m. auditų

Dažniausios spragos yra įprasti valdysenos trūkumai.

Pirma, organizacijos pamiršta, kad MDR paslaugų teikėjai gali tvarkyti asmens duomenis. Saugumo žurnalai kartais laikomi „techniniais duomenimis“, tačiau juose gali būti asmens duomenų ir kartais jautraus turinio. GDPR vaidmenų analizė ir duomenų tvarkytojo nuostatos turi būti parengtos prieš paslaugos paleidimą, o ne pažeidimo metu.

Antra, žurnalų saugojimas laikomas savaime suprantamu, o ne įtvirtinamas sutartyje. Jeigu reglamentavimo, skaitmeninės kriminalistikos ar klientų pareigos reikalauja įrodymų mėnesiams, MDR ir SIEM saugojimo modelis turi tai palaikyti. MVĮ politikos reikalavimas dėl 12 mėnesių paslaugų teikėjo žurnalų saugojimo yra praktiškas bazinis reikalavimas daugeliui aplinkų.

Trečia, trečiųjų šalių prieiga yra pernelyg plati. Paslaugų teikėjo paskyros turi būti vardinės, apsaugotos MFA, stebimos, peržiūrimos ir, kai įmanoma, ribotos laiko atžvilgiu. Bendros paskyros ir nevaldomos administravimo sesijos kelia audito ir reagavimo į incidentus riziką.

Ketvirta, incidentų slenksčiai neaiškūs. MDR kritiškumas automatiškai nereiškia teisinio incidento, DORA reikšmingo su IRT susijusio incidento, NIS2 reikšmingo incidento ar GDPR asmens duomenų saugumo pažeidimo. Reagavimo veiksmų planas turi apibrėžti, kas priima kiekvieną sprendimą.

Penkta, subtiekėjai nematomi. Jeigu MDR paslaugų teikėjas keičia analizės platformas, pagalbos regionus ar žemiau grandinėje esančius duomenų tvarkytojus, keičiasi kliento rizikos vaizdas. Išankstinis rašytinis sutikimas ir periodinė peržiūra yra būtini.

Šešta, paslaugų peržiūros sutelkiamos tik į užklausų kiekį. Brandžios peržiūros nagrinėja praleistus perspėjimus, derinimo pakeitimus, žurnalų šaltinių būklę, įrodymų gavimą, paslaugų teikėjo prieigą, bendradarbiavimą incidentų metu ir sutartines pareigas.

Tolesni žingsniai: parenkite savo MDR paslaugų teikėją auditui su Clarysec

Jeigu jūsų MDR paslaugų teikėjas jau veikia, nelaukite reguliuotojo, kliento auditoriaus ar incidento, kad sužinotumėte, jog jūsų įrodymai neišsamūs. Pradėkite nuo vieno neseno perspėjimo ir sukurkite pėdsaką. Tada klasifikuokite paslaugų teikėją, peržiūrėkite sutartį, validuokite žurnalų tvarkymą, testuokite eskalavimą, patvirtinkite duomenų tvarkytojo nuostatas, peržiūrėkite prieigą ir suplanuokite tiekėjų stebėseną.

Clarysec gali padėti tai greitai pritaikyti praktikoje naudojant:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint etapiniam įgyvendinimui, įskaitant Step 19 žurnalų tvarkymo, stebėsenos ir prieigos tikrinimui, ir Step 23 tiekėjų bei incidentų valdymo kontrolės priemonėms.
• Zenith Controls: The Cross-Compliance Guide Zenith Controls, skirtą susieti ISO/IEC 27002:2022 kontrolės priemones 5.19, 5.22 ir 8.15 su NIS2, DORA, GDPR, NIST ir COBIT audito lūkesčiais.
• Clarysec politikų šablonus, įskaitant 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 ir Data Protection and Privacy Policy - SME.

MDR yra viena vertingiausių saugumo investicijų, kurią organizacija gali atlikti. 2026 m. šią vertę reikės įrodyti per valdyseną, įrodymus ir atskaitingą priežiūrą. Jei norite praktinio MDR priežiūros paketo, susieto su ISO/IEC 27001:2022, NIS2, DORA ir GDPR Article 32, Clarysec gali padėti jį sukurti prieš tai, kai kitas perspėjimas taps kita audito išvada.