MDR-teenuseosutaja järelevalve NIS2, DORA ja GDPR nõuete kontekstis

Esmaspäeva hommikul kell 02:13 avab MDR-teenuseosutaja kõrge raskusastmega teavituse: võimatu reisimuster, kahtlased postkasti reeglid ja privilegeeritud konto, mida kasutatakse haldamata lõppseadmest. SOC-i analüütik eskaleerib juhtumi piletihaldusportaali kaudu. Teie IT-juht magab. Finantsjuht saab pangakontaktilt andmepüügihoiatuse enne, kui sisemine intsidendikanal reageerib. Kella 07:30ks seisab infoturbejuht silmitsi kolme ebamugava küsimusega.

Kellel oli volitus intsident välja kuulutada?

Kas suudame tõendada, et MDR-teenuseosutajal olid õiged logid, et neid säilitati piisavalt kaua ja et tõendusmaterjal säilitati nõuetekohaselt?

Kui isikuandmetele pääseti juurde, kas õigusfunktsioon suudab täita GDPR rikkumise hindamise tähtajad samal ajal, kui operatiivmeeskonnad valmistavad ette NIS2 või DORA aruandlust?

Kuu aega hiljem küsib välisaudiitor sama tõendusmaterjali teistsuguses toonis. MDR-teenuseosutaja PDF-aruanne on kasulik, kuid sellest ei piisa. Audiitor soovib toorteavituste andmeid, täielikke logifaile, eskaleerimise auditijälge, sisemist otsustuslogi, tarnija ülevaatuse kirjet ja tõendit selle kohta, et organisatsioon suutis toimunut sõltumatult kontrollida.

See on 2026. aasta MDR-teenuseosutaja järelevalve probleem. Organisatsioonid hangivad tuvastuse ja reageerimise allhankena, sest sisemine SOC-i võimekus on kallis, värbamine keeruline ja ohutegevus lakkamatu. Kuid tuvastuse allhange ei tähenda vastutuse allhanget. NIS2 kohaselt vastutavad juhtorganid jätkuvalt küberriskide juhtimise meetmete heakskiitmise ja järelevalve eest. DORA kohaselt vastutavad finantsüksused täielikult kolmandatest isikutest IKT-teenuseosutajatega seotud riski eest, sealhulgas kriitiliste IKT-teenuste, intsidenditoe, auditeerimisõiguste, alltöövõtu ja teenuse lõpetamise eest. GDPR kohaselt peavad vastutavad töötlejad tõendama töötlemise asjakohast turvalisust, eriti kui volitatud töötlejad käitlevad telemeetriat, lõppseadmete andmeid, kasutajatunnuseid, IP-aadresse, e-kirjade sisu, logisid või digitaalse kohtuekspertiisi tõmmiseid.

Praktiline lünk ei ole enamasti ainult MDR-lepingus. See on tõendusahel lepingu ja tegeliku teenuse vahel: teavituste suunamine, privilegeeritud juurdepääs, logide säilitamine, eskaleerimislävendid, intsidendi tõendusmaterjal, alltöövõtjate läbipaistvus, volitatud töötleja klauslid, teenuse ülevaatused, lauaõppused ja juhtkonna aruandlus.

Kaitstav MDR-teenuseosutaja järelevalve programm vajab üht tegevusmudelit, mis katab mitu auditiarutelu. ISO/IEC 27001:2022 annab selleks selgroo.

MDR-i järelevalve algab vastutusest, mitte SOC-i konsoolist

Levinud viga on käsitleda MDR-i kasutuselevõttu tehnilise projektina: EDR-agentide juurutamine, identiteedilogide edastamine, teavituste konfigureerimine, Teamsi või Slacki kanali kokkuleppimine ja tootmiskeskkonda üleminek. See võib parandada tuvastust, kuid ei tõenda juhtimist.

NIS2 teeb probleemi selgesõnaliseks. Olulised ja tähtsad üksused peavad rakendama asjakohaseid ja proportsionaalseid tehnilisi, operatiivseid ja organisatsioonilisi küberriskide juhtimise meetmeid. Article 21 hõlmab riskianalüüsi, intsidentide käsitlemist, talitluspidevust, tarneahela turvet, küberhügieeni, juurdepääsukontrolli, varahaldust, krüptograafiat ja mitmefaktorilist autentimist. Article 20 tõstab selle juhtorgani vastutuse tasandile, nõudes nende meetmete heakskiitmist ja järelevalvet.

MDR-teenuseosutajad paiknevad sageli korraga mitmes NIS2 Article 21 valdkonnas:

• Intsidentide käsitlemine, sest teenuseosutaja teeb triaaži, eskaleerib ja võib soovitada ohjeldamismeetmeid.
• Tarneahela turve, sest teenuseosutaja on otsene teenuseosutaja, kellel on operatiivne turbemõju.
• Juurdepääsukontroll, sest teenuseosutaja võib pääseda juurde konsoolidele, logidele, lõppseadme tööriistadele või pilverentnikele.
• Logimine ja seire, sest tuvastus sõltub logide katvusest, säilitamisest ja korrelatsioonist.
• Küberhügieen, sest MDR-i leiud toovad sageli esile paikamise, identiteedi või konfiguratsiooni nõrkused.
• Talitluspidevus, sest viivitatud reageerimine võib häirida kriitilisi teenuseid.

Finantsüksuste puhul muudab DORA tegevusmudeli rangemaks. DORA kohaldub alates 17. jaanuarist 2025 ning nõuab IKT-riski juhtimist, intsidentidest teatamist, digitaalse tegevuskerksuse testimist, teabejagamist ja kolmandatest isikutest IKT-teenuseosutajatega seotud riskijuhtimist. Samuti selgitab see, et finantsüksuste puhul, kes on tuvastatud ka NIS2 alusel, toimib DORA kattuvate küberkaitsekohustuste osas sektoripõhise liidu õigusaktina. Reguleeritud pank, makseasutus, investeerimisühing, kindlustusandja või krüptovarateenuse osutaja ei saa lihtsalt öelda: „Meie MDR-teenuseosutaja tegeleb sellega.“ DORA eeldab, et üksus klassifitseerib IKT-intsidendid, juhib ja jälgib kolmandatest isikutest IKT-teenuseosutajaid, peab IKT-teenusekorralduste registreid, määratleb lepingulised õigused, testib tegevuskerksust, teeb algpõhjuse analüüsi ning teatab suurematest IKT-ga seotud intsidentidest etappide kaupa.

GDPR lisab teistsuguse vaatenurga. Kui MDR-i telemeetria hõlmab kasutajatunnuseid, IP-aadresse, e-posti metaandmeid, autentimiskirjeid, lõppseadme artefakte või isikuandmeid sisaldavaid faile, kohalduvad GDPR turvalisuse ja vastutuse põhimõtted. Article 5 hõlmab terviklust, konfidentsiaalsust ja vastutust. Article 32 töötlemise turvalisus muutub praktiliseks tõendusküsimuseks: kas logid olid kaitstud, kas juurdepääs oli piiratud, kas vajaduse korral kasutati krüptimist, kas volitatud töötlejaid juhiti ning kas organisatsioon suudab toimunut tõendada?

Sõnum on kõigis kolmes režiimis sama: töö saab delegeerida, vastutust mitte.

ISO/IEC 27001:2022 muudab MDR-i auditeeritavaks protsessiks

Hästi rakendatud ISO/IEC 27001:2022 põhine ISMS muudab MDR-teenuseosutaja järelevalve tarnijahalduslikust lubadusest tõenduspõhiseks tegevusmudeliks. Clause 8.1 on eriti oluline, sest see nõuab, et organisatsioonid ohjaksid ISMS-i seisukohast asjakohaseid väljastpoolt pakutavaid protsesse, tooteid ja teenuseid. MDR on täpselt selline protsess: väljastpoolt pakutav protsess, mis võib mõjutada intsidentidele reageerimist, privaatsust, tegevuskerksust, regulatiivset aruandlust ja talitluspidevust.

MDR-i järelevalve seisukohast kõige olulisemad ISO/IEC 27001:2022 Annex A valdkonnad hõlmavad tarnijasuhteid, tarnijalepingute turbenõudeid, IKT tarneahela riskijuhtimist, tarnijateenuste seiret, intsidendihaldust, tõendusmaterjali käitlemist, logimist, seiret, juurdepääsukontrolli, privilegeeritud juurdepääsu, krüptograafiat ja talitluspidevuse valmisolekut.

Claryseci Zenith Controls: The Cross-Compliance Guide Zenith Controls on selle töö vastavusülese seostamise viide. See seostab ISO/IEC 27002:2022 kontrollimeetmed muude nõuete, seotud kontrollimeetmete, auditi ootuste ja rakendamise tõendusmaterjaliga. MDR-i järelevalves on kesksed kolm ISO/IEC 27002:2022 kontrollimeedet: 5.19 tarnijasuhete jaoks, 5.22 tarnijateenuste seire ja muudatuste juhtimise jaoks ning 8.15 logimise jaoks. Neid toetavad 5.20 tarnijalepingud, 5.21 IKT tarneahela turve, 5.24 kuni 5.28 intsidendihaldus ja tõendusmaterjali käitlemine, 5.34 privaatsus ja isikuandmed, 5.36 vastavus, 8.16 seiretegevused, 8.17 kella sünkroniseerimine, 8.18 privilegeeritud utiliitprogrammide kasutamine ja 8.8 tehniliste haavatavuste haldus.

See on oluline, sest MDR-i auditileid ütleb harva „MDR puudub“. Tavaliselt ütleb see üht järgmistest:

• MDR-teenuseosutajat ei olnud klassifitseeritud kriitiliseks.
• Lepingutingimused ei hõlmanud intsidendist teavitamist, juurdepääsu tõendusmaterjalile ega auditeerimisõigusi.
• Logisid ei säilitatud piisavalt kaua, et uurida teatatud sündmust.
• Teenuseosutaja juurdepääs oli jagatud, püsiv või seireta.
• Klient ei vaadanud MDR-i toimivust SLA-de suhtes üle.
• Alltöövõtjaid või alltöötlejaid ei olnud heaks kiidetud.
• Isikuandmete rikkumisest teatamise kohustused ei olnud joondatud intsidentide töövoogudega.
• Tõendusmaterjali ei säilitatud digitaalse kohtuekspertiisi seisukohast kasutataval viisil.
• Juhtkonnal puudusid mõõdikud, mis näitaksid, kas MDR-teenus vähendas riski.

Zenith Controls sõnastab tarnijaootuste ja lepingute seose selgelt:

„5.19 määrab turbeootused selle kohta, kuidas tarnijad peavad organisatsiooni teavet käitlema. 5.20 vormistab need ootused, tagades, et lepingud või kokkulepped sisaldavad selgesõnaliselt turbeklausleid, näiteks konfidentsiaalsusnõudeid, turvapoliitikate järgimist ja intsidendist teavitamise protseduure. Ilma 5.20ta ei pruugi punktis 5.19 tuvastatud nõuded olla õiguslikult jõustatavad.“

MDR-i puhul on see lause juhtimisõppetund. Kui leping ei nõua teenuseosutajalt logide säilitamist, tõendusmaterjali esitamist, intsidentides koostööd, alltöövõtu piiramist, auditite toetamist ja eskaleerimistähtaegade järgimist, võib SOC-teenus olla operatiivselt kasulik, kuid auditite seisukohast nõrk.

Mida peab MDR-leping tõendama enne esimest teavitust

Hea MDR-leping ei ole ainult äriline tellimusvorm. See on kontrollidokument. DORA Articles 28 to 30 nõuavad, et kolmandatest isikutest IKT-teenuseosutajatega seotud riski juhitaks kogu elutsükli jooksul, sealhulgas IKT-lepingute registrid, kriitilisuse klassifitseerimine, lepingueelne hoolsuskohustus, auditi- ja kontrollimeetodid, lõpetamisõigused, väljumisstrateegiad, selged teenusekirjeldused, teenustasemed, teenuse osutamise ja andmetöötluse asukohad, andmekaitsekohustused, intsidendiabi ning koostöö asutustega. NIS2 Article 21 nõuab tarneahela turvet otseste tarnijate ja teenuseosutajate puhul. GDPR nõuab vastutava töötleja ja volitatud töötleja rollide, volitatud töötleja garantiide, andmekaitseklauslite ja töötlemise turvalisuse tõendusmaterjali määratlemist.

Claryseci poliitikakogu teisendab need kohustused praktilisteks lepingulisteks ja operatiivseteks nõueteks. Enterprise Incident Response Policy Incident Response Policy käsitleb MDR-i selgesõnaliselt juhitud kolmanda osapoole intsidendivõimekusena:

„Integratsioon kolmandate osapoolte teenustega, sealhulgas Managed Detection and Response (MDR), Security Incident and Event Management (SIEM) ja digitaalse kohtuekspertiisi analüüsi teenuseosutajad, peab olema reguleeritud selgelt määratletud teenustaseme lepingute (SLA-d) ja konfidentsiaalsussätetega.“

See klausel on oluline, sest MDR-teenuseosutajad saavad sageli väga tundlikku teavet enne, kui organisatsioon teab, kas intsidendist tuleb teatada. Telemeetria võib sisaldada kasutajanimesid, failiteid, e-kirjade teemaridasid, sisemisi hostinimesid, IP-aadresse, võrguskeeme ja kompromiteerimise indikaatoreid. Konfidentsiaalsussätted kaitsevad organisatsiooni uurimise ajal ja toetavad GDPR kohast vastutust.

Enterprise Third party and supplier security policy Third party and supplier security policy lisab kaks klauslit, mida audiitorid MDR-i järelevalve ülevaatamisel eeldavad:

„Õigus auditeerida, kontrollida ja taotleda turbe tõendusmaterjali“

ja:

„Alltöövõtjate kasutamine eelneva kirjaliku nõusoleku alusel“

VKE-de puhul vähendatakse sama juhtimispõhimõtte ulatust, kuid seda ei kõrvaldata. Third-Party and Supplier Security Policy - SME Third-Party and Supplier Security Policy - SME nõuab vähima privileegi põhimõtet:

„Tarnijatele tuleb anda juurdepääs ainult nende ülesande täitmiseks vajalikele minimaalsetele süsteemidele ja andmetele.“

Samuti nõuab see:

„Täiendava alltöövõtu piirangud ilma heakskiiduta“

Need klauslid on MDR-i puhul eriti asjakohased. Paljud teenuseosutajad kasutavad mitmetasandilisi SOC-i meeskondi, platvormitarnijaid, ohuteabe partnereid, pilveanalüütika teenuseid või piirkondlikku tugipersonali. Kui allavoolu osapooled saavad ligipääsu kliendi logidele või isikuandmetele, vajab klient nähtavust ja heakskiidumehhanisme. DORA mõistes on see osa alltöövõtu ja kontsentratsiooniriski järelevalvest. GDPR mõistes on see alltöötlejate juhtimine. NIS2 mõistes on see tarneahela riskijuhtimine.

MDR-i järelevalve põhiline kontrollnimekiri

Kaitstav MDR-teenuseosutaja suhe peab olema testitav. Järgmine kontrollnimekiri ühendab lepingulised, operatiivsed ja tõendusnõuded üheks kontrollivaateks.

See kontrollnimekiri tuleb lõimida hangetesse, kasutuselevõttu, perioodilistesse läbivaatamistesse ja intsidenditestimisse. Kui mõni punkt puudub, peab organisatsioon käsitlema seda tarnijariskina, mitte dokumendiprobleemina.

Seitse tõendusvaldkonda, mida audiitorid eeldavad

MDR-i järelevalve auditivalmiduse tagamiseks soovitab Clarysec luua MDR-i tõendusfaili, mis on korraldatud seitsmesse valdkonda. See fail peab asuma ISMS-is, mitte hankekaustas, mida keegi üle ei vaata.

See tabel muudab vestlust teenuseosutajaga. Küsimuse „Kas te seirate meid?“ asemel küsib organisatsioon: „Kas suudame igas kvartalis tõendada, et MDR-teenus on jätkuvalt tõhus, nõuetele vastav ja meie riskivalmidusega kooskõlas?“

Logimine on sild tuvastuse ja vastavustõendite vahel

MDR ilma usaldusväärse logimiseta on allhangitud oletamine. Teenuseosutaja võib tuvastada osa ohte, kuid organisatsioon ei suuda tõendada ulatust, ajajoont, algpõhjust ega mõju.

ISO/IEC 27002:2022 kontrollimeede 8.15 käsitleb logimist. Zenith Controls klassifitseerib logimise tuvastava kontrollimeetmena, mis toetab konfidentsiaalsust, terviklust ja käideldavust ning on joondatud Detect küberkaitsekontseptsiooni ja infoturbe sündmuste halduse võimekusega. See seob logimise otseselt seiretegevuste, sündmuste hindamise, intsidentidele reageerimise, õppetundide, privilegeeritud juurdepääsu, kella sünkroniseerimise, juurdepääsukontrolli, privaatsuse, tõendite kogumise, haavatavuste halduse ja füüsilise turbe seirega.

Seetõttu on logimine NIS2, DORA ja GDPR Article 32 tõendusmaterjali keskne osa. NIS2 Article 23 oluliste intsidentide aruandlus nõuab varajast hoiatust 24 tunni jooksul teadlikuks saamisest, teavitust 72 tunni jooksul ja lõpparuannet hiljemalt ühe kuu jooksul pärast teavitamist. DORA suuremate IKT-ga seotud intsidentide aruandlus nõuab klassifitseerimist, eskaleerimist, kommunikatsiooni, algpõhjuse analüüsi ja lõpparuandlust. GDPR vastutus nõuab, et organisatsioonid tõendaksid, mis isikuandmetega juhtus ja kas turvameetmed olid asjakohased.

Claryseci Logging and Monitoring Policy - SME Logging and Monitoring Policy - SME pakub väiksematele organisatsioonidele, kes kasutavad väliseid teenuseosutajaid, lihtsa lepingulise kontrollimeetme:

„Lepingud peavad nõudma, et teenuseosutajad säilitaksid logisid vähemalt 12 kuud ja annaksid taotluse korral juurdepääsu.“

Ettevõttekeskkondade jaoks lisab Logging and Monitoring Policy Logging and Monitoring Policy operatiivse integratsiooni nõude:

„Peab taotluse korral esitama logiandmed või integreeruma organisatsiooni SIEM-i/logide koondamise platvormiga.“

Need klauslid lahendavad korduva intsidentidele reageerimise probleemi: uurimise ajal ütleb MDR-teenuseosutaja, et sündmus on otsitavast säilitusaknast vanem, logid on saadaval ainult tasulise digitaalse kohtuekspertiisi ekspordi kaudu või kliendi SIEM ei sisalda teenuseosutaja rikastusi ja analüütikute toiminguid. Kui juurdepääs logidele ei ole eelnevalt määratletud, muutub intsidendi ajajoon killustatuks.

Tugev MDR-i logimismudel peab määratlema kohustuslikud logiallikad, sündmuseliigid, säilitustähtajad, tervikluskaitse, juurdepääsukinnitused, aja sünkroniseerimise, ekspordivormingud ning korrelatsioonireeglid kliendi ja teenuseosutaja platvormide vahel. Samuti peab see hõlmama teenuseosutaja toiminguid, sealhulgas tuvastusreeglite muudatusi, lõppseadmete isoleerimise käske, haldusjuurdepääsu, analüütikute märkmeid ja tõendusmaterjali eksporti.

ISO toetavad standardid kinnitavad seda lähenemist. ISO/IEC 27035-1:2023 ja ISO/IEC 27035-2:2023 seovad logimise intsidendi tuvastuse, triaaži ja keskse analüüsiga. ISO/IEC 27701:2021 lisab isikuandmete töötlemistoimingute privaatsuspõhise logimise. ISO/IEC 27017:2021 ja ISO/IEC 27018:2020 lisavad pilve ja pilves töödeldavate isikuandmete logimise ootused, eriti kui teenuseosutajad töötlevad kliendiandmeid avalikes pilvekeskkondades. ISO/IEC 27005:2024 käsitleb ebapiisavat logimist riski käsitlemise küsimusena, mitte üksnes tööriistalüngana.

Intsidentidele reageerimine: MDR saab eskaleerida, kuid juhtkond peab otsustama

MDR-teenuseosutajad tuvastavad ja nõustavad. Vastutav organisatsioon kuulutab intsidendid välja, hindab regulatiivset mõju, suhtleb asutustega ja otsustab, kas isikuandmete rikkumisest tuleb teatada.

See eristus on oluline, sest MDR-i raskusaste ei võrdu automaatselt NIS2 olulise intsidendi, DORA suurema IKT-ga seotud intsidendi ega GDPR isikuandmete rikkumisega. Teenuseosutaja võib märgistada teavituse „kõrge raskusastmega“, kuid organisatsioon peab otsustama, kas kriitilisi teenuseid mõjutati, kas isikuandmed kompromiteeriti, kas kliente tuleb teavitada, kas järelevalveasutusi tuleb teavitada ja kas juhtkond peab heaks kiitma operatiivse mõjuga ohjeldamismeetme.

Claryseci Incident Response Policy - SME Incident Response Policy - SME on otsesõnaline:

„Kolmandad osapooled peavad tegutsema kooskõlas allkirjastatud lepingutega, mis peavad sisaldama isikuandmete rikkumisest teavitamise klausleid ja koostööpõhise reageerimise kohustusi.“

See klausel on koht, kus GDPR Article 32 tõendusmaterjal kohtub operatiivse intsidentidele reageerimisega. Kui MDR-teenuseosutaja märkab kahtlustatavat andmete väljaviimist lõppseadmest, mis sisaldab isikuandmeid, peab teenuseosutaja teadma, kui kiiresti teavitada, keda teavitada, millist tõendusmaterjali säilitada ja kuidas toetada vastutava töötleja hindamist.

Claryseci Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint annab testimismeetodi. Controls in Action faasis, Step 19, juhendab Zenith Blueprint meeskondi logimist ja seiret operatiivselt valideerima:

„Valige hiljutine intsident või sündmus ja näidake, kuidas te selle oma logide abil tuvastasite. Kui kasutatakse logide tervikluse funktsioone (nt räsiväärtuse kontroll), dokumenteerige ka see. Kinnitage, et teavitamine toimib (nt ebaõnnestunud sisselogimised või õiguste eskaleerimised käivitavad teavitused).“

Sama samm käsitleb identiteeti ja privilegeeritud juurdepääsu:

„Privilegeeritud kontode puhul kontrollige, et MFA on rakendatud, administraatorirollid on lahutatud (admin_john-tüüpi kontosid kasutatakse ainult haldusülesanneteks) ja olemas on ajakohane privilegeeritud kasutajate loend.“

MDR-i kontekstis peab privilegeeritud kasutajate loend hõlmama teenuseosutaja kontosid, mitte ainult töötajaid. Kui MDR-teenuseosutajal on konsoolijuurdepääs, lõppseadme isoleerimise õigused, EDR-i haldusõigused või lugemisõigus tundlikele logidele, kuuluvad need kontod ülevaatusse.

Zenith Blueprint Step 23 annab seejärel intsidendi ja tarnija testistruktuuri:

„Valige hiljutine sündmus või viige läbi lauaõppus, et oma plaani valideerida. Salvestage ja logige kõik otsused, rollid ja teabevahetus (5.26) ning ajakohastage plaani õppetundide põhjal (5.27). Kinnitage, et olemas on protseduurid digitaalse kohtuekspertiisi tõendusmaterjali säilitamiseks (5.28), sealhulgas logitõmmised, varukoopiad ja mõjutatud süsteemide turvaline isoleerimine.“

Realistlik lauaõppus peab hõlmama MDR-teenuseosutajat. Kasutage stsenaariumi, näiteks kompromiteeritud privilegeeritud konto, lõppseadme isoleerimine, kahtlustatav postkasti juurdepääs, võimalik palgaandmete avalikustumine ja teavituse eskaleerimine väljaspool tööaega. Test peab kontrollima, kas MDR-teenuseosutaja „kell“ käivitub tuvastamisel, kliendi teavitamisel või kliendi kinnituse saamisel. See eristus on oluline, kui regulatiivsed tähtajad sõltuvad teadlikuks saamise ja otsustamise hetkedest.

Koosta ühe teavituse MDR-i järelevalvepakett 90 minutiga

Kiire viis lünkade esiletoomiseks on valida üks hiljutine kõrge raskusastmega MDR-teavitus ja koostada ühe lehekülje pikkune tõendusjälg. See praktiline harjutus töötab hästi enne auditeid, juhatuse ülevaatusi ja lepingute uuendamist.

1. Alustage teavituse piletist. Fikseerige ajatempel, tuvastusreegel, mõjutatud vara, kasutaja, raskusaste, MDR-analüütiku märkmed ja eskaleerimistee.
2. Võtke välja lepinguklausel või SLA, mis näitab selle raskusastme eeldatavat reageerimisaega.
3. Hankige logiallikate loend, mis tõendab, millised süsteemid teavitust toitsid, näiteks EDR, identiteedipakkuja, tulemüür, e-posti turvalüüs ja pilve auditilogid.
4. Kinnitage, et logisid säilitatakse poliitika kohaselt ja et ajaloolist sündmust saab endiselt kätte saada.
5. Kontrollige, kas MDR-analüütik pääses mõnda kliendikeskkonda. Kui jah, fikseerige nimeline konto, MFA tõendusmaterjal, seansilogid ja kinnitus.
6. Dokumenteerige kliendipoolne otsus: sündmus suleti, intsident kuulutati välja, käivitati õiguslik hindamine, viidi läbi ohjeldamine või risk aktsepteeriti.
7. Kui isikuandmed võivad olla seotud, dokumenteerige GDPR rollianalüüs, rikkumise hindamise omanik ja kas volitatud töötleja teavitamiskohustused käivitati.
8. Lõpetage õppetundidega: häälestus, uus tuvastus, juurdepääsumuudatus, tööjuhise uuendus või tarnija SLA probleem.

See ühe teavituse jälg on mõjus, sest see ühendab lepingu, logimise, juurdepääsu, intsidentidele reageerimise, privaatsuse ja juhtkonna järelevalve üheks tõendusahelaks. Kui te ei suuda seda hiljutise teavituse kohta koostada, ei suuda te seda tõenäoliselt koostada ka regulatiivse surve all.

Tarnija seire on koht, kus enamik MDR-programme nõrgeneb

Paljud organisatsioonid teevad enne MDR-lepingu allkirjastamist taustakontrolli ja seejärel lõpetavad. Sellest ei piisa ISO/IEC 27001:2022, NIS2, DORA ega GDPR jaoks. MDR-teenused muutuvad pidevalt: uued tuvastusreeglid, uued analüütikumeeskonnad, uued alltöötlejad, uued andmepiirkonnad, uued EDR-võimekused, uued integratsioonid, uued ohuteabe vood ja uued tugimudelid.

ISO/IEC 27002:2022 kontrollimeede 5.22 käsitleb tarnijateenuste seiret, läbivaatamist ja muudatuste juhtimist. Zenith Controls selgitab, et 5.22 tugineb tarnijasuhte ja kokkulepete kontrollimeetmetele, tagades pärast teenuse käivitamist pideva seire ja juhtimise. See seostub turvalisusega katkestuse ajal, haavatavuste halduse, vastavuse, juurdepääsukontrolli ja turvalise arendusega.

DORA Articles 28 to 30 muudavad selle finantsüksuste jaoks eriti oluliseks. Need nõuavad pidevat seiret, kolmandatest isikutest IKT-teenuseosutajatega seotud korralduste registreid, kriitilisuse eristusi, taustakontrolli, auditi- ja kontrolliõigusi, lõpetamisõigusi, väljumisstrateegiaid, teenustasemeid, intsidendiabi, koostööd asutustega ning kriitiliste või oluliste funktsioonide puhul teenuse-eesmärke, varuplaanide testimist ja vajaduse korral koostööd ohupõhise läbistustestimise korral.

Zenith Blueprint, Controls in Action faas, Step 23, annab tarnija elutsükli struktuuri:

„Koostage täielik nimekiri praegustest tarnijatest ja teenuseosutajatest (5.19) ning klassifitseerige need süsteemidele, andmetele või operatiivsele kontrollile juurdepääsu alusel.“

See jätkub:

„Iga kriitilise tarnija puhul tuvastage, kas nad kasutavad alltöövõtjaid (alltöötlejaid), kellel võib olla juurdepääs teie andmetele või süsteemidele.“

Praktiline MDR-teenuse ülevaatus tuleb kriitilistes keskkondades korraldada kord kvartalis ja madalama riskiga keskkondades vähemalt kord aastas. Päevakord peab hõlmama SLA täitmist raskusastme lõikes, eskaleeritud teavitusi, tõelisi positiivseid leide, valepositiivseid leide, vahelejäänud eskaleerimisi, logiallikate seisundit, privilegeeritud juurdepääsu muudatusi, uusi integratsioone, uusi piirkondi, alltöövõtjaid, alltöötlejaid, tuvastusreeglite muudatusi, intsidenditoe toimivust, tõendusmaterjali päringuid, avatud riske, parandusmeetmeid ja väljumisvalmidust.

See ei ole mikrotasandi juhtimine. See on kindlust andev tagasisideahel, mis tõendab, et organisatsioon juhib aktiivselt kriitilist turbetarnijat.

Vastavusülene seostamine: üks MDR-i kontrollikomplekt, viis auditiarutelu

ISO/IEC 27001:2022 väärtus seisneb selles, et see annab organisatsioonidele ühe sidusa ISMS-tsükli mitme vastavusarutelu jaoks. Sama MDR-i järelevalve tõenduspaketti saab seostada NIS2, DORA, GDPR, NIST CSF 2.0 ja COBIT 2019 nõuetega.

NIST CSF 2.0 on kasulik suhtluseks. Selle GOVERN funktsioon nõuab, et õiguslikud, regulatiivsed, lepingulised ja privaatsuskohustused oleksid mõistetud ja juhitud, rollid ja volitused määratletud, küberrisk integreeritud ettevõtte riskijuhtimisse ning tarnijariskid kommunikeeritud ja seiratud.

COBIT 2019 on kasulik juhtimise ja kindlustunde jaoks. COBIT-põhised audiitorid keskenduvad sageli vähem ühele kontrollimeetmele ja rohkem sellele, kas juhtimiseesmärgid, teenusehaldus, riskivastutus ja toimivuse seire toimivad süsteemina.

Kuidas audiitorid MDR-teenuseosutaja järelevalvet testivad

Erinevad audiitorid kasutavad erinevaid vaatenurki, kuid kõik soovivad tõendusmaterjali selle kohta, et organisatsioon ohjab suhet.

ISO/IEC 27001:2022 audiitor alustab kohaldamisalast, huvitatud osapooltest, riskihindamisest, kohaldatavusdeklaratsioonist (SoA), riski käsitlemise plaanist ja operatiivsest tõendusmaterjalist. Kui MDR kuulub kohaldamisalasse, eeldab audiitor, et väljastpoolt pakutavad protsessid on ISMS-i raames ohjatud. Ta võib valimisse võtta tarnijasuhted, tarnijalepingud, tarnijateenuste seire, logimise, seire, intsidentidele reageerimise, tõendusmaterjali käitlemise ja juurdepääsukontrolli.

DORA järelevalveasutus keskendub talitluspidevusele ja süsteemsele riskile. Ta võib põhjalikult kontrollida kriitilisuse hindamist, IKT-teenuste registrit, kontsentratsiooniriski analüüsi, väljumisstrateegiat, intsidentide klassifitseerimist, auditeerimisõigusi ja tõendusmaterjali selle kohta, et MDR-teenuseosutaja suudab toetada regulatiivset aruandlust.

GDPR audiitor või privaatsuse ülevaataja keskendub vastutava töötleja ja volitatud töötleja juhtimisele. Ta küsib andmetöötluslepingut, volitatud töötleja taustakontrolli, alltöötlejate kontrollimeetmeid, isikuandmeid sisaldavate logide kaitsemeetmeid, säilitamise kontrollimeetmeid, rikkumise hindamise kirjeid ja Article 32 toetavat tõendusmaterjali.

COBIT või ISACA audiitor kontrollib juhtimise tõendusmaterjali: tarnijariski omanikku, hanketöövoogu, teenuse ülevaatuse protokolle, SLA probleemide jälgimist, parandusmeetmeid, tõendusmaterjali kvaliteeti ja seda, kas juhtkond saab sisukaid mõõdikuid.

Kõige paljastavam auditipäring on lihtne: „Näidake mulle üht MDR-teavitust tuvastamisest sulgemiseni.“ Kui suudate näidata lepingulist ootust, logiallikat, teavitust, eskaleerimist, otsust, tõendusmaterjali säilitamist, privaatsushinnangut, parandusmeetmeid ja juhtkonna aruandlust, on teie MDR-i järelevalve küps. Kui suudate näidata ainult tarnija piletit, on teil seire, kuid nõrk juhtimine.

Juhtkonna aruandlus: juhatus ei vaja paketitõmmiseid

NIS2 ja DORA asetavad vastutuse juhtorgani tasandile. Juhatused ja tippjuhid ei vaja toortelemeetriat. Nad vajavad riskiga seotud MDR-i järelevalve mõõdikuid.

Kasulik kvartaalne MDR-i juhtpaneel sisaldab järgmist:

• Kasutusele võetud kriitilised logiallikad võrreldes eeldatuga.
• MDR-iga kaetud kriitiliste varade osakaal.
• Kõrge raskusastmega teavitused kategooria ja äriteenuse kaupa.
• Keskmine aeg tuvastamisest kliendi teavitamiseni.
• Keskmine aeg kliendi kinnitusest otsuseni.
• SLA rikkumised ja lahendamata teenuseosutaja tegevused.
• Privilegeeritud teenuseosutaja kontode ülevaatuse staatus.
• Alltöövõtjate või alltöötlejate muudatused.
• Intsidendid, mis nõuavad õiguslikku, regulatiivset või kliendi teavitamise hindamist.
• Rakendatud õppetunnid.

See juhtpaneel peab olema sisendiks ISMS-i juhtkonnapoolsele läbivaatamisele, riski käsitlemise ajakohastustele ja tarnija ülevaatusele. ISO/IEC 27001:2022 kohaselt peab juhtkond tagama, et ISMS on kooskõlas strateegilise suunaga, ressursid on kättesaadavad, vastutused on määratud, kommunikatsioon toimib ja toimub pidev täiustamine. MDR-i mõõdikud on praktiline viis näidata, et allhangitud turbeoperatsioonid on juhtkonna juhitud, mitte jäetud tööriistade administraatorite hooleks.

Levinud MDR-i järelevalve puudujäägid, mis tuleb enne 2026. aasta auditeid kõrvaldada

Kõige levinumad lüngad on tavalised juhtimispuudused.

Esiteks unustavad organisatsioonid, et MDR-teenuseosutajad võivad töödelda isikuandmeid. Turbelogisid käsitletakse mõnikord „tehniliste andmetena“, kuid need võivad sisaldada isikuandmeid ja aeg-ajalt tundlikku sisu. GDPR rollianalüüs ja volitatud töötleja klauslid tuleb lõpetada enne kasutuselevõttu, mitte rikkumise ajal.

Teiseks eeldatakse logide säilitamist, kuid seda ei lepingustata. Kui regulatiivsed, digitaalse kohtuekspertiisi või kliendikohustused nõuavad tõendusmaterjali kuudeks, peab MDR-i ja SIEM-i säilitamismudel seda toetama. VKE poliitika nõue teenuseosutaja logide 12-kuuliseks säilitamiseks on paljude keskkondade jaoks praktiline baastase.

Kolmandaks on kolmandate osapoolte juurdepääs liiga lubav. Teenuseosutaja kontod peavad olema nimelised, MFA-ga kaitstud, seiratud, üle vaadatud ja võimaluse korral ajaliselt piiratud. Ühiskontod ja haldamata haldusseansid tekitavad auditiriski ja intsidentidele reageerimise riski.

Neljandaks on intsidendilävendid ebaselged. MDR-i raskusaste ei võrdu automaatselt õigusliku intsidendi, DORA suurema IKT-ga seotud intsidendi, NIS2 olulise intsidendi ega GDPR isikuandmete rikkumisega. Tööjuhis peab määratlema, kes iga otsuse teeb.

Viiendaks on alltöövõtjad nähtamatud. Kui MDR-teenuseosutaja muudab analüüsiplatvorme, tugipiirkondi või allavoolu volitatud töötlejaid, muutub kliendi riskipilt. Eelnev kirjalik nõusolek ja perioodiline läbivaatamine on hädavajalikud.

Kuuendaks keskenduvad teenuse ülevaatused ainult piletite mahule. Küpsed ülevaatused käsitlevad vahelejäänud teavitusi, häälestusmuudatusi, logiallikate seisundit, tõendusmaterjali kättesaamist, teenuseosutaja juurdepääsu, intsidendikoostööd ja lepingulisi kohustusi.

Järgmised sammud: tee oma MDR-teenuseosutaja Claryseciga auditiks valmis

Kui teie MDR-teenuseosutaja on juba aktiivses kasutuses, ärge oodake, kuni regulaator, kliendi audiitor või intsident paljastab, et teie tõendusmaterjal on puudulik. Alustage ühest hiljutisest teavitusest ja koostage jälg. Seejärel klassifitseerige teenuseosutaja, vaadake leping üle, valideerige logimine, testige eskaleerimist, kinnitage volitatud töötleja klauslid, vaadake juurdepääs üle ja ajastage tarnija seire.

Clarysec aitab teil selle kiiresti tööle panna, kasutades järgmisi vahendeid:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint etapiviisiliseks rakendamiseks, sealhulgas Step 19 logimise, seire ja juurdepääsu valideerimiseks ning Step 23 tarnija ja intsidendihalduse kontrollimeetmete jaoks.
• Zenith Controls: The Cross-Compliance Guide Zenith Controls, et seostada ISO/IEC 27002:2022 kontrollimeetmed 5.19, 5.22 ja 8.15 NIS2, DORA, GDPR, NIST ja COBIT auditi ootustega.
• Claryseci poliitikamallid, sealhulgas 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 ja Data Protection and Privacy Policy - SME.

MDR on üks väärtuslikumaid turbeinvesteeringuid, mida organisatsioon saab teha. 2026. aastal tuleb seda väärtust tõendada juhtimise, tõendusmaterjali ja vastutava järelevalve kaudu. Kui soovite praktilist MDR-i järelevalvepaketti, mis on seostatud ISO/IEC 27001:2022, NIS2, DORA ja GDPR Article 32 nõuetega, saab Clarysec aidata teil selle üles ehitada enne, kui järgmine teavitus muutub järgmiseks auditileiuks.