MDR pakalpojumu sniedzēja pārraudzība NIS2, DORA un GDPR prasībām

Pirmdienas rītā plkst. 02:13 MDR pakalpojumu sniedzējs atver augstas smaguma pakāpes brīdinājumu: neiespējamas pārvietošanās indikators, aizdomīgi pastkastes noteikumi un priviliģēts konts, kas izmantots no nepārvaldītas galiekārtas. SOC analītiķis eskalē notikumu pieteikumu portālā. Jūsu IT vadītājs guļ. Finanšu direktors saņem pikšķerēšanas brīdinājumu no bankas kontaktpersonas, pirms iekšējais incidentu kanāls ir aktivizēts. Plkst. 07:30 CISO jau saskaras ar trim neērtiem jautājumiem.

Kam bija pilnvaras deklarēt incidentu?

Vai varam pierādīt, ka MDR pakalpojumu sniedzējam bija pieejami pareizie žurnāli, ka tie tika glabāti pietiekami ilgi un ka pierādījumi tika saglabāti?

Ja tika piekļūts personas datiem, vai juridiskais dienests var ievērot GDPR pārkāpuma izvērtēšanas termiņus, kamēr operāciju komanda sagatavo NIS2 vai DORA ziņošanu?

Mēnesi vēlāk ārējais auditors pieprasa tos pašus pierādījumus citā tonī. MDR pakalpojumu sniedzēja PDF pārskats ir noderīgs, bet ar to nepietiek. Auditoram ir vajadzīgi neapstrādāti brīdinājumu dati, pilni žurnālfaili, eskalācijas audita pieraksts, iekšējais lēmumu žurnāls, piegādātāja pārskatīšanas ieraksts un pierādījums, ka organizācija varēja neatkarīgi pārbaudīt notikušo.

Tā ir 2026. gada MDR pakalpojumu sniedzēja pārraudzības problēma. Organizācijas nodod atklāšanu un reaģēšanu ārpakalpojumā, jo iekšējā SOC kapacitāte ir dārga, personāla piesaiste ir sarežģīta un apdraudējumu aktivitāte ir nepārtraukta. Tomēr ārpakalpojumā nodota atklāšana nenozīmē ārpakalpojumā nodotu pārskatatbildību. Saskaņā ar NIS2 pārvaldības institūcijas saglabā atbildību par kiberdrošības risku pārvaldības pasākumu apstiprināšanu un pārraudzību. Saskaņā ar DORA finanšu subjekti saglabā pilnu atbildību par IKT trešo pušu risku, tostarp kritiskiem IKT pakalpojumiem, atbalstu incidentos, audita tiesībām, apakšuzņēmēju izmantošanu un izstāšanos. Saskaņā ar GDPR pārziņiem ir jāpierāda atbilstoša apstrādes drošība, jo īpaši gadījumos, kad apstrādātāji rīkojas ar telemetriju, galiekārtu datiem, lietotāju identifikatoriem, IP adresēm, e-pasta saturu, žurnāliem vai digitālās kriminālistikas attēliem.

Praktiskā nepilnība reti ir tikai MDR līgums. Tā ir pierādījumu ķēde starp līgumu un aktīvo pakalpojumu: brīdinājumu maršrutēšana, priviliģēta piekļuve, žurnālu glabāšana, eskalācijas sliekšņi, incidentu pierādījumi, apakšuzņēmēju pārredzamība, apstrādātāja klauzulas, pakalpojumu pārskatīšana, galda mācības un vadības ziņošana.

Aizstāvamai MDR pakalpojumu sniedzēja pārraudzības programmai ir vajadzīgs viens darbības modelis, kas atbilst vairākām audita sarunām. ISO/IEC 27001:2022 nodrošina šo pamatu.

MDR pārraudzība sākas ar pārskatatbildību, nevis SOC konsoli

Izplatīta kļūda ir MDR ieviešanu uztvert kā tehnisku projektu: izvietot EDR aģentus, pārsūtīt identitātes žurnālus, konfigurēt brīdinājumus, vienoties par Teams vai Slack kanālu un sākt ekspluatāciju. Tas var uzlabot atklāšanu, bet nepierāda pārvaldību.

NIS2 šo jautājumu formulē skaidri. Būtiskām un svarīgām vienībām ir jāievieš atbilstoši un samērīgi tehniski, operatīvi un organizatoriski kiberdrošības risku pārvaldības pasākumi. Article 21 ietver risku analīzi, incidentu apstrādi, darbības nepārtrauktību, piegādes ķēdes drošību, kiberdrošības higiēnu, piekļuves kontroli, aktīvu pārvaldību, kriptogrāfiju un daudzfaktoru autentifikāciju. Article 20 to paceļ pārvaldības institūciju pārskatatbildības līmenī, pieprasot šo pasākumu apstiprināšanu un pārraudzību.

MDR pakalpojumu sniedzēji bieži vienlaikus aptver vairākas NIS2 Article 21 jomas:

• Incidentu apstrādi, jo pakalpojumu sniedzējs veic triāžu, eskalē notikumus un var ieteikt ierobežošanas pasākumus.
• Piegādes ķēdes drošību, jo pakalpojumu sniedzējs ir tiešs pakalpojumu sniedzējs ar ietekmi uz operacionālo drošību.
• Piekļuves kontroli, jo pakalpojumu sniedzējs var piekļūt konsolēm, žurnāliem, galiekārtu rīkiem vai mākoņvides nomniekiem.
• Žurnālfiksēšanu un uzraudzību, jo atklāšana ir atkarīga no žurnālu pārklājuma, glabāšanas un korelācijas.
• Kiberdrošības higiēnu, jo MDR konstatējumi bieži atklāj ielāpošanas, identitātes vai konfigurācijas vājās vietas.
• Darbības nepārtrauktību, jo novēlota reaģēšana var traucēt kritiskus pakalpojumus.

Finanšu subjektiem DORA pastiprina darbības modeli. DORA piemēro no 2025. gada 17. janvāra un prasa IKT risku pārvaldību, incidentu ziņošanu, noturības testēšanu, informācijas apmaiņu un IKT trešo pušu risku pārvaldību. Tā arī precizē, ka finanšu subjektiem, kuri identificēti arī saskaņā ar NIS2, DORA attiecībā uz pārklājošiem kiberdrošības pienākumiem darbojas kā nozares specifisks Savienības tiesību akts. Regulēta banka, maksājumu iestāde, ieguldījumu sabiedrība, apdrošinātājs vai kriptoaktīvu pakalpojumu sniedzējs nevar vienkārši pateikt: “To apstrādā mūsu MDR pakalpojumu sniedzējs.” DORA sagaida, ka subjekts klasificē IKT incidentus, pārvalda un uzrauga IKT trešo pušu pakalpojumu sniedzējus, uztur IKT pakalpojumu vienošanos reģistrus, nosaka līgumiskās tiesības, testē noturību, veic pamatcēloņa analīzi un pakāpeniski ziņo par būtiskiem ar IKT saistītiem incidentiem.

GDPR pievieno citu skatījumu. Ja MDR telemetrija ietver lietotāju identifikatorus, IP adreses, e-pasta metadatus, autentifikācijas ierakstus, galiekārtu artefaktus vai datnes, kas satur personas datus, tad piemērojami GDPR drošības un pārskatatbildības principi. Article 5 ietver integritāti, konfidencialitāti un pārskatatbildību. Article 32 apstrādes drošība kļūst par praktisku pierādījumu jautājumu: vai žurnāli tika aizsargāti, vai piekļuve bija ierobežota, vai vajadzības gadījumā tika izmantota šifrēšana, vai apstrādātāji tika pārvaldīti un vai organizācija var pierādīt notikušo?

Vēstījums visos trīs režīmos ir vienāds: darbu var deleģēt, bet atbildību deleģēt nevar.

ISO/IEC 27001:2022 pārvērš MDR par auditējamu procesu

Labi ieviesta uz ISO/IEC 27001:2022 balstīta informācijas drošības pārvaldības sistēma pārvērš MDR pakalpojumu sniedzēja pārraudzību no piegādātāju pārvaldības solījuma par pierādījumos balstītu darbības modeli. Clause 8.1 ir īpaši svarīga, jo tā prasa organizācijām kontrolēt ārēji nodrošinātus procesus, produktus un pakalpojumus, kas ir būtiski IDPS. MDR ir tieši šāds process: ārēji nodrošināts process, kas var ietekmēt incidentu reaģēšanu, privātumu, noturību, regulatīvo ziņošanu un darbības nepārtrauktību.

Svarīgākās ISO/IEC 27001:2022 Annex A jomas MDR pārraudzībai ietver piegādātāju attiecības, drošības prasības piegādātāju vienošanās, IKT piegādes ķēdes risku pārvaldību, piegādātāju pakalpojumu uzraudzību, incidentu pārvaldību, pierādījumu apstrādi, žurnālfiksēšanu, uzraudzību, piekļuves kontroli, priviliģētu piekļuvi, kriptogrāfiju un gatavību darbības nepārtrauktībai.

Clarysec Zenith Controls: The Cross-Compliance Guide Zenith Controls ir šī darba starpatbilstības atsauce. Tas kartē ISO/IEC 27002:2022 kontroles pasākumus pret citām prasībām, saistītajiem kontroles pasākumiem, audita gaidām un ieviešanas pierādījumiem. MDR pārraudzībai centrāli ir trīs ISO/IEC 27002:2022 kontroles pasākumi: 5.19 piegādātāju attiecībām, 5.22 piegādātāju pakalpojumu uzraudzībai un izmaiņu pārvaldībai, un 8.15 žurnālfiksēšanai. Tos atbalsta 5.20 piegādātāju vienošanās, 5.21 IKT piegādes ķēdes drošība, 5.24 līdz 5.28 incidentu pārvaldība un pierādījumu apstrāde, 5.34 privātums un PII, 5.36 atbilstība, 8.16 uzraudzības darbības, 8.17 pulksteņu sinhronizācija, 8.18 priviliģētu utilītprogrammu izmantošana un 8.8 tehnisko ievainojamību pārvaldība.

Tas ir svarīgi, jo MDR audita neveiksme reti nozīmē “nav MDR”. Parasti tā nozīmē kādu no šiem gadījumiem:

• MDR pakalpojumu sniedzējs nebija klasificēts kā kritisks.
• Līguma klauzulās nebija iekļauta paziņošana par incidentiem, piekļuve pierādījumiem vai audita tiesības.
• Žurnāli netika glabāti pietiekami ilgi, lai izmeklētu ziņotu notikumu.
• Pakalpojumu sniedzēja piekļuve bija koplietota, pastāvīga vai neuzraudzīta.
• Klients nepārskatīja MDR veiktspēju attiecībā pret SLA.
• Apakšuzņēmēji vai apakšapstrādātāji nebija apstiprināti.
• Personas datu aizsardzības pārkāpuma paziņošanas pienākumi nebija saskaņoti ar incidentu darbplūsmām.
• Pierādījumi netika saglabāti digitālās kriminālistikas vajadzībām izmantojamā veidā.
• Vadībai nebija metrikas, kas parādītu, vai MDR pakalpojums samazina risku.

Zenith Controls skaidri formulē saikni starp piegādātāju gaidām un vienošanām:

“5.19 nosaka drošības gaidas attiecībā uz to, kā piegādātājiem jāapstrādā organizācijas informācija. 5.20 formalizē šīs gaidas, nodrošinot, ka līgumos vai vienošanās ir skaidri iekļautas drošības klauzulas, piemēram, konfidencialitātes prasības, atbilstība drošības politikām un incidentu paziņošanas procedūras. Bez 5.20 prasības, kas identificētas 5.19, var nebūt juridiski izpildāmas.”

MDR gadījumā šis teikums ir pārvaldības mācība. Ja līgums neprasa pakalpojumu sniedzējam glabāt žurnālus, sniegt pierādījumus, sadarboties incidentos, ierobežot apakšuzņēmēju izmantošanu, atbalstīt auditus un ievērot eskalācijas termiņus, SOC pakalpojums var būt operacionāli noderīgs, bet audita ziņā vājš.

Kas MDR līgumam jāpierāda pirms pirmā brīdinājuma

Labs MDR līgums nav tikai komerciāls pasūtījuma dokuments. Tas ir kontroles dokuments. DORA Articles 28 to 30 prasa pārvaldīt IKT trešo pušu risku visā dzīves ciklā, tostarp uzturēt IKT līgumu reģistrus, veikt kritiskuma klasifikāciju, pirmslīguma sākotnējo izpēti, noteikt audita un pārbaudes pieejas, izbeigšanas tiesības, izstāšanās stratēģijas, skaidrus pakalpojumu aprakstus, pakalpojumu līmeņus, pakalpojuma un datu apstrādes atrašanās vietas, datu aizsardzības saistības, atbalstu incidentos un sadarbību ar iestādēm. NIS2 Article 21 prasa piegādes ķēdes drošību tiešajiem piegādātājiem un pakalpojumu sniedzējiem. GDPR prasa pārziņa un apstrādātāja lomas, apstrādātāja garantijas, datu aizsardzības klauzulas un apstrādes drošības pierādījumus.

Clarysec politiku bibliotēka pārvērš šos pienākumus praktiskās līguma un darbības prasībās. Enterprise Incident Response Policy Incident Response Policy MDR skaidri traktē kā pārvaldītu trešās puses incidentu spēju:

“Integrācija ar trešo pušu pakalpojumiem, tostarp Managed Detection and Response (MDR), Security Incident and Event Management (SIEM) un digitālās kriminālistikas pakalpojumu sniedzējiem, ir jāpārvalda ar skaidri definētām pakalpojumu līmeņa vienošanās (SLA) un neizpaušanas noteikumiem.”

Šī klauzula ir svarīga, jo MDR pakalpojumu sniedzēji bieži saņem ļoti sensitīvu informāciju, pirms organizācija zina, vai incidents ir ziņojams. Telemetrija var ietvert lietotājvārdus, datņu ceļus, e-pasta tematus, iekšējos resursdatoru nosaukumus, IP adreses, tīkla shēmas un kompromitācijas indikatorus. Neizpaušanas noteikumi aizsargā organizāciju izmeklēšanas laikā un atbalsta GDPR pārskatatbildību.

Enterprise Third party and supplier security policy Third party and supplier security policy pievieno divas klauzulas, ko auditori sagaida redzēt, pārskatot MDR pārraudzību:

“Tiesības veikt auditu, pārbaudi un pieprasīt drošības pierādījumus”

un:

“Apakšuzņēmēju izmantošana ar iepriekšēju rakstisku piekrišanu”

SME gadījumā tas pats pārvaldības princips tiek mērogots uz leju, bet netiek atcelts. Third-Party and Supplier Security Policy - SME Third-Party and Supplier Security Policy - SME prasa minimāli nepieciešamās tiesības:

“Piegādātājiem drīkst piešķirt piekļuvi tikai minimālajām sistēmām un datiem, kas nepieciešami viņu funkcijas izpildei.”

Tā arī prasa:

“Ierobežojumi turpmākai apakšuzņēmēju izmantošanai bez apstiprinājuma”

Šīs klauzulas ir īpaši būtiskas MDR kontekstā. Daudzi pakalpojumu sniedzēji izmanto daudzlīmeņu SOC komandas, platformu piegādātājus, draudu izlūkošanas partnerus, mākoņanalītikas pakalpojumus vai reģionālo atbalsta personālu. Ja pakārtotās puses var piekļūt klienta žurnāliem vai personas datiem, klientam ir vajadzama redzamība un apstiprināšanas mehānismi. DORA izpratnē tā ir daļa no apakšuzņēmēju un koncentrācijas riska pārraudzības. GDPR izpratnē tā ir apakšapstrādātāju pārvaldība. NIS2 izpratnē tā ir piegādes ķēdes risku pārvaldība.

Būtiskais MDR pārraudzības kontrolsaraksts

Aizstāvamām MDR pakalpojumu sniedzēja attiecībām jābūt pārbaudāmām. Tālāk norādītais kontrolsaraksts apvieno līgumiskās, operacionālās un pierādījumu prasības vienā kontroles skatā.

Šis kontrolsaraksts jāiestrādā iepirkumā, ieviešanā, periodiskajā pārskatīšanā un incidentu testēšanā. Ja kāds punkts trūkst, organizācijai tas jāuzskata par piegādātāja risku, nevis dokumentācijas jautājumu.

Septiņas pierādījumu jomas, ko sagaida auditori

Lai MDR pārraudzība būtu gatava auditam, Clarysec iesaka izveidot MDR pierādījumu datni, kas sakārtota septiņās jomās. Šai datnei jāatrodas IDPS, nevis iepirkumu mapē, kuru neviens nepārskata.

Šī tabula maina sarunu ar pakalpojumu sniedzēju. Tā vietā, lai jautātu: “Vai jūs mūs uzraugāt?”, organizācija jautā: “Vai katru ceturksni varam pierādīt, ka MDR pakalpojums joprojām ir efektīvs, atbilstošs un saskaņots ar mūsu riska apetīti?”

Žurnālfiksēšana ir tilts starp atklāšanu un atbilstības pierādījumiem

MDR bez uzticamas žurnālfiksēšanas ir ārpakalpojumā nodota minēšana. Pakalpojumu sniedzējs var atklāt daļu apdraudējumu, bet organizācija nevar pierādīt tvērumu, laika skalu, pamatcēloni vai ietekmi.

ISO/IEC 27002:2022 kontroles pasākums 8.15 aptver žurnālfiksēšanu. Zenith Controls klasificē žurnālfiksēšanu kā atklājošu kontroles pasākumu, kas atbalsta konfidencialitāti, integritāti un pieejamību, ir saskaņots ar Detect kiberdrošības konceptu un informācijas drošības notikumu pārvaldības spēju. Tas tieši sasaista žurnālfiksēšanu ar uzraudzības darbībām, notikumu izvērtēšanu, reaģēšanu uz incidentiem, gūtajām mācībām, priviliģētu piekļuvi, pulksteņu sinhronizāciju, piekļuves kontroli, privātumu, pierādījumu vākšanu, ievainojamību pārvaldību un fiziskās drošības uzraudzību.

Tāpēc žurnālfiksēšana ir centrāla NIS2, DORA un GDPR Article 32 pierādījumiem. NIS2 Article 23 ziņošana par nozīmīgiem incidentiem prasa agrīnu brīdinājumu 24 stundu laikā pēc uzzināšanas, paziņojumu 72 stundu laikā un gala ziņojumu ne vēlāk kā vienu mēnesi pēc paziņojuma. DORA ziņošana par būtiskiem ar IKT saistītiem incidentiem prasa klasifikāciju, eskalāciju, komunikāciju, pamatcēloņa analīzi un gala ziņošanu. GDPR pārskatatbildība prasa organizācijām pierādīt, kas notika ar personas datiem un vai drošības pasākumi bija atbilstoši.

Clarysec Logging and Monitoring Policy - SME Logging and Monitoring Policy - SME nodrošina vienkāršu līgumisku kontroli mazākām organizācijām, kas izmanto ārējus pakalpojumu sniedzējus:

“Līgumos ir jāprasa, lai pakalpojumu sniedzēji glabā žurnālus vismaz 12 mēnešus un nodrošina piekļuvi pēc pieprasījuma”

Uzņēmumu vidēm Logging and Monitoring Policy Logging and Monitoring Policy pievieno operacionālās integrācijas prasību:

“Pēc pieprasījuma jāsniedz žurnālu dati vai jāintegrējas ar organizācijas SIEM/žurnālu agregēšanas platformu.”

Šīs klauzulas risina atkārtotu incidentu reaģēšanas problēmu: izmeklēšanas laikā MDR pakalpojumu sniedzējs norāda, ka notikums ir vecāks par meklēšanai pieejamo glabāšanas logu, žurnāli ir pieejami tikai ar maksas kriminālistisko eksportu vai klienta SIEM nesatur pakalpojumu sniedzēja bagātinājumus un analītiķu darbības. Ja piekļuve žurnāliem nav definēta iepriekš, incidenta laika skala kļūst sadrumstalota.

Stipram MDR žurnālfiksēšanas modelim jādefinē obligātie žurnālu avoti, notikumu tipi, glabāšanas termiņi, integritātes aizsardzība, piekļuves apstiprinājumi, laika sinhronizācija, eksporta formāti un korelācijas noteikumi starp klienta un pakalpojumu sniedzēja platformām. Tam jāaptver arī pakalpojumu sniedzēja darbības, tostarp atklāšanas noteikumu izmaiņas, galiekārtu izolēšanas komandas, administratīvā piekļuve, analītiķu piezīmes un pierādījumu eksporti.

ISO atbalsta standarti nostiprina šo pieeju. ISO/IEC 27035-1:2023 un ISO/IEC 27035-2:2023 sasaista žurnālfiksēšanu ar incidentu atklāšanu, triāžu un centralizētu analīzi. ISO/IEC 27701:2021 pievieno privātumam specifisku PII apstrādes darbību žurnālfiksēšanu. ISO/IEC 27017:2021 un ISO/IEC 27018:2020 pievieno mākoņpakalpojumu un mākoņvidē apstrādātas PII žurnālfiksēšanas gaidas, īpaši gadījumos, kad pakalpojumu sniedzēji apstrādā klienta datus publiskās mākoņvidēs. ISO/IEC 27005:2024 nepietiekamu žurnālfiksēšanu definē kā riska apstrādes jautājumu, nevis tikai rīku nepilnību.

Reaģēšana uz incidentiem: MDR var eskalēt, bet vadībai jāpieņem lēmums

MDR pakalpojumu sniedzēji atklāj un konsultē. Pārskatatbildīgā organizācija deklarē incidentus, izvērtē regulatīvo ietekmi, sazinās ar iestādēm un lemj, vai ir nepieciešams paziņojums par personas datu aizsardzības pārkāpumu.

Šī atšķirība ir svarīga, jo MDR smaguma pakāpe automātiski nenozīmē NIS2 nozīmīgu incidentu, DORA būtisku ar IKT saistītu incidentu vai GDPR personas datu aizsardzības pārkāpumu. Pakalpojumu sniedzējs var atzīmēt brīdinājumu kā “augstas smaguma pakāpes”, bet organizācijai jālemj, vai tika ietekmēti kritiski pakalpojumi, vai tika kompromitēti personas dati, vai jāinformē klienti, vai jāinformē regulatori un vai vadībai jāapstiprina ierobežošanas darbība ar operacionālu ietekmi.

Clarysec Incident Response Policy - SME Incident Response Policy - SME ir tieša:

“Trešajām pusēm jārīkojas saskaņā ar parakstītajām vienošanām, kurās jāiekļauj personas datu aizsardzības pārkāpuma paziņošanas klauzulas un sadarbības pienākumi reaģēšanā.”

Šī klauzula ir vieta, kur GDPR Article 32 pierādījumi satiekas ar operacionālu reaģēšanu uz incidentiem. Ja MDR pakalpojumu sniedzējs novēro aizdomas par datu neatļautu iznesi no galiekārtas, kurā ir personas dati, pakalpojumu sniedzējam jāzina, cik ātri jāziņo, kam jāziņo, kādi pierādījumi jāsaglabā un kā atbalstīt pārziņa izvērtējumu.

Clarysec Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint sniedz testēšanas metodi. Controls in Action posmā, Step 19, Zenith Blueprint norāda komandām operacionāli validēt žurnālfiksēšanu un uzraudzību:

“Izvēlieties nesenu incidentu vai notikumu un parādiet, kā to izsekojāt, izmantojot savus žurnālus. Ja tiek izmantotas žurnālu integritātes funkcijas (piemēram, hešvērtības pārbaude), dokumentējiet arī tās. Apstipriniet, ka brīdināšana darbojas (piemēram, neveiksmīgas pieteikšanās vai privilēģiju paaugstināšana aktivizē brīdinājumus).”

Tas pats solis attiecas uz identitāti un priviliģētu piekļuvi:

“Priviliģētajiem kontiem pārbaudiet, ka MFA ir obligāta, administratora lomas ir nodalītas (admin_john tipa konti tiek izmantoti tikai administratora uzdevumiem) un pastāv aktuāls priviliģēto lietotāju saraksts.”

MDR kontekstā priviliģēto lietotāju sarakstā jāiekļauj pakalpojumu sniedzēja konti, ne tikai darbinieki. Ja MDR pakalpojumu sniedzējam ir piekļuve konsolēm, galiekārtu izolēšanas tiesības, EDR administrēšanas tiesības vai lasīšanas piekļuve sensitīviem žurnāliem, šie konti ietilpst pārskatīšanā.

Zenith Blueprint Step 23 sniedz incidentu un piegādātāju testēšanas struktūru:

“Izvēlieties nesenu notikumu vai veiciet galda mācības, lai validētu savu plānu. Fiksējiet un reģistrējiet visus lēmumus, lomas un komunikāciju (5.26) un atjauniniet plānu ar gūtajām mācībām (5.27). Apstipriniet, ka ir ieviestas procedūras digitālās kriminālistikas pierādījumu saglabāšanai (5.28), tostarp žurnālu momentuzņēmumi, rezerves kopijas un ietekmēto sistēmu droša izolācija.”

Reālistiskās galda mācībās jāiekļauj MDR pakalpojumu sniedzējs. Izmantojiet scenāriju, piemēram, kompromitēts priviliģēts konts, galiekārtas izolēšana, aizdomas par piekļuvi pastkastei, iespējama algu datu ekspozīcija un brīdinājuma eskalācija ārpus darba laika. Testā jāpārbauda, vai MDR pakalpojumu sniedzēja laika atskaite sākas ar atklāšanu, klienta informēšanu vai klienta apstiprinājumu. Šī atšķirība ir būtiska, ja regulatīvie termiņi ir atkarīgi no uzzināšanas un lēmumu pieņemšanas punktiem.

Izveidojiet viena MDR brīdinājuma pārraudzības pakotni 90 minūtēs

Ātrs veids, kā atklāt nepilnības, ir izvēlēties vienu nesenu augstas smaguma pakāpes MDR brīdinājumu un izveidot vienas lapas pierādījumu izsekojamību. Šis praktiskais vingrinājums labi darbojas pirms auditiem, valdes pārskatiem un līgumu atjaunošanas.

1. Sāciet ar brīdinājuma pieteikumu. Fiksējiet laikspiedolu, atklāšanas noteikumu, ietekmēto aktīvu, lietotāju, smaguma pakāpi, MDR analītiķa piezīmes un eskalācijas ceļu.
2. Atrodiet līguma klauzulu vai SLA, kas parāda sagaidāmo reaģēšanas laiku šai smaguma pakāpei.
3. Izgūstiet žurnālu avotu sarakstu, kas pierāda, kuras sistēmas nodrošināja brīdinājumu, piemēram, EDR, identitātes nodrošinātājs, ugunsmūris, e-pasta drošības vārteja un mākoņa audita žurnāli.
4. Apstipriniet, ka žurnāli tiek glabāti saskaņā ar politiku un ka vēsturisko notikumu joprojām var izgūt.
5. Pārbaudiet, vai MDR analītiķis piekļuva kādai klienta videi. Ja jā, fiksējiet vārdisko kontu, MFA pierādījumus, sesiju žurnālus un apstiprinājumu.
6. Dokumentējiet klienta puses lēmumu: notikums slēgts, incidents deklarēts, sākta juridiskā izvērtēšana, veikta ierobežošana vai risks pieņemts.
7. Ja var būt iesaistīti personas dati, pierakstiet GDPR lomu analīzi, pārkāpuma izvērtēšanas īpašnieku un to, vai tika aktivizēti apstrādātāja paziņošanas pienākumi.
8. Noslēdziet ar gūtajām mācībām: regulēšana, jauna atklāšana, piekļuves izmaiņas, rokasgrāmatas atjauninājums vai piegādātāja SLA problēma.

Šī viena brīdinājuma izsekojamība ir spēcīga, jo vienā pierādījumu ķēdē sasaista līgumu, žurnālfiksēšanu, piekļuvi, reaģēšanu uz incidentiem, privātumu un vadības pārraudzību. Ja to nevarat izveidot par nesenu brīdinājumu, visticamāk nevarēsiet to izveidot regulatīva spiediena apstākļos.

Piegādātāja uzraudzība ir vieta, kur vairums MDR programmu kļūst vājas

Daudzas organizācijas veic sākotnējo izpēti pirms MDR līguma parakstīšanas un pēc tam apstājas. Ar to nepietiek ISO/IEC 27001:2022, NIS2, DORA vai GDPR vajadzībām. MDR pakalpojumi nepārtraukti mainās: jauni atklāšanas noteikumi, jaunas analītiķu komandas, jauni apakšapstrādātāji, jauni datu reģioni, jaunas EDR iespējas, jaunas integrācijas, jaunas draudu izlūkošanas plūsmas un jauni atbalsta modeļi.

ISO/IEC 27002:2022 kontroles pasākums 5.22 attiecas uz piegādātāju pakalpojumu uzraudzību, pārskatīšanu un izmaiņu pārvaldību. Zenith Controls skaidro, ka 5.22 balstās uz piegādātāju attiecību un vienošanos kontroles pasākumiem, nodrošinot nepārtrauktu uzraudzību un pārvaldību pēc pakalpojuma uzsākšanas. Tas saistās ar drošību traucējumu laikā, ievainojamību pārvaldību, atbilstību, piekļuves kontroli un drošu inženieriju.

DORA Articles 28 to 30 to padara īpaši svarīgu finanšu subjektiem. Tie prasa pastāvīgu uzraudzību, IKT trešo pušu vienošanos reģistrus, kritiskuma nošķīrumus, sākotnējo izpēti, audita un pārbaudes tiesības, izbeigšanas tiesības, izstāšanās stratēģijas, pakalpojumu līmeņus, atbalstu incidentos, sadarbību ar iestādēm un kritiskām vai svarīgām funkcijām — pakalpojumu mērķus, ārkārtas situāciju testēšanu un sadarbību apdraudējumu vadītā ielaušanās testēšanā, ja tas ir piemērojami.

Zenith Blueprint, Controls in Action posms, Step 23, sniedz piegādātāja dzīves cikla struktūru:

“Apkopojiet pilnu pašreizējo piegādātāju un pakalpojumu sniedzēju sarakstu (5.19) un klasificējiet tos pēc piekļuves sistēmām, datiem vai operacionālās kontroles.”

Tas turpina:

“Katram kritiskajam piegādātājam identificējiet, vai tas izmanto apakšuzņēmējus (apakšapstrādātājus), kuri var piekļūt jūsu datiem vai sistēmām.”

Praktiska MDR pakalpojuma pārskatīšana kritiskām vidēm jāveic reizi ceturksnī, bet zemāka riska vidēm — vismaz reizi gadā. Darba kārtībā jāiekļauj SLA atbilstība pēc smaguma pakāpes, eskalētie brīdinājumi, patiesi pozitīvie gadījumi, kļūdaini pozitīvie gadījumi, nokavētās eskalācijas, žurnālu avotu darbspēja, priviliģētas piekļuves izmaiņas, jaunas integrācijas, jauni reģioni, apakšuzņēmēji, apakšapstrādātāji, atklāšanas noteikumu izmaiņas, atbalsta incidentos veiktspēja, pierādījumu pieprasījumi, atvērtie riski, korektīvās darbības un gatavība izstāšanās procesam.

Tā nav mikropārvaldība. Tā ir apliecinājuma cilpa, kas pierāda, ka organizācija aktīvi pārvalda kritisku drošības piegādātāju.

Starpatbilstības kartēšana: viens MDR kontroles pasākumu kopums, piecas audita sarunas

ISO/IEC 27001:2022 vērtība ir tajā, ka tas organizācijām dod vienu saskaņotu IDPS ciklu vairākām atbilstības sarunām. To pašu MDR pārraudzības pierādījumu pakotni var kartēt pret NIS2, DORA, GDPR, NIST CSF 2.0 un COBIT 2019.

NIST CSF 2.0 ir noderīgs komunikācijai. Tā GOVERN funkcija prasa izprast un pārvaldīt juridiskos, regulatīvos, līgumiskos un privātuma pienākumus, definēt lomas un pilnvaras, integrēt kiberdrošības risku uzņēmuma risku pārvaldībā un komunicēt un uzraudzīt piegādātāju riskus.

COBIT 2019 ir noderīgs vadībai un apliecinājumam. COBIT orientēti auditori bieži mazāk koncentrējas uz vienu kontroles pasākumu un vairāk uz to, vai pārvaldības mērķi, pakalpojumu pārvaldība, atbildība par risku un veiktspējas uzraudzība darbojas kā sistēma.

Kā auditori testēs MDR pakalpojumu sniedzēja pārraudzību

Dažādi auditori izmanto dažādus skatījumus, bet visi vēlas pierādījumus, ka organizācija kontrolē attiecības.

ISO/IEC 27001:2022 auditors sāks ar darbības jomu, ieinteresētajām pusēm, risku izvērtēšanu, piemērojamības deklarāciju, risku apstrādes plānu un operacionālajiem pierādījumiem. Ja MDR ietilpst darbības jomā, auditors sagaidīs, ka ārēji nodrošinātie procesi tiek kontrolēti IDPS ietvaros. Viņš var atlasīt paraugus no piegādātāju attiecībām, piegādātāju vienošanām, piegādātāju pakalpojumu uzraudzības, žurnālfiksēšanas, uzraudzības, reaģēšanas uz incidentiem, pierādījumu apstrādes un piekļuves kontroles.

DORA uzraugs koncentrēsies uz operacionālo noturību un sistēmisko risku. Tas var rūpīgi pārbaudīt kritiskuma izvērtēšanu, IKT pakalpojumu reģistru, koncentrācijas riska analīzi, izstāšanās stratēģiju, incidentu klasifikāciju, audita tiesības un pierādījumus, ka MDR pakalpojumu sniedzējs var atbalstīt regulatīvo ziņošanu.

GDPR auditors vai privātuma izvērtētājs koncentrēsies uz pārziņa un apstrādātāja pārvaldību. Viņš pieprasīs DPA, apstrādātāja sākotnējo izpēti, apakšapstrādātāju kontroles pasākumus, drošības pasākumus žurnāliem, kas satur personas datus, glabāšanas kontroles pasākumus, pārkāpuma izvērtēšanas ierakstus un pierādījumus, kas atbalsta Article 32.

COBIT vai ISACA auditors pārbaudīs pārvaldības pierādījumus: atbildību par piegādātāja risku, iepirkuma darbplūsmu, pakalpojumu pārskatīšanas protokolus, SLA problēmu izsekošanu, korektīvās darbības, pierādījumu kvalitāti un to, vai vadība saņem jēgpilnu metriku.

Atklājošākais audita pieprasījums ir vienkāršs: “Parādiet vienu MDR brīdinājumu no atklāšanas līdz slēgšanai.” Ja varat parādīt līguma gaidas, žurnālu avotu, brīdinājumu, eskalāciju, lēmumu, pierādījumu saglabāšanu, privātuma izvērtēšanu, trūkumu novēršanu un vadības ziņošanu, jūsu MDR pārraudzība ir nobriedusi. Ja varat parādīt tikai piegādātāja pieteikumu, jums ir uzraudzība, bet vāja pārvaldība.

Vadības ziņošana: valdei nav vajadzīgi pakešu uztvērumi

NIS2 un DORA abi nosaka atbildību pārvaldības institūciju līmenī. Valdēm un augstākajai vadībai nav vajadzīga neapstrādāta telemetrija. Viņiem vajadzīga ar risku saistīta MDR pārraudzības metrika.

Noderīgs ceturkšņa MDR informācijas panelis ietver:

• Kritisko žurnālu avotu ievadi salīdzinājumā ar sagaidāmo.
• MDR aptverto kritisko aktīvu procentuālo daļu.
• Augstas smaguma pakāpes brīdinājumus pēc kategorijas un biznesa pakalpojuma.
• Vidējo laiku no atklāšanas līdz klienta paziņošanai.
• Vidējo laiku no klienta apstiprinājuma līdz lēmumam.
• SLA pārkāpumus un neatrisinātas pakalpojumu sniedzēja darbības.
• Priviliģēto pakalpojumu sniedzēja kontu pārskatīšanas statusu.
• Apakšuzņēmēju vai apakšapstrādātāju izmaiņas.
• Incidentus, kuriem nepieciešama juridiska, regulatīva vai klientu paziņošanas izvērtēšana.
• Ieviestās gūtās mācības.

Šim informācijas panelim jābaro IDPS vadības pārskatīšana, risku apstrādes atjauninājumi un piegādātāja pārskatīšana. Saskaņā ar ISO/IEC 27001:2022 vadībai jānodrošina, ka IDPS ir saskaņota ar stratēģisko virzienu, ir pieejami resursi, ir piešķirti pienākumi, komunikācija darbojas un notiek nepārtraukta uzlabošana. MDR metrika ir praktisks veids, kā parādīt, ka ārpakalpojumā nodotās drošības operācijas pārvalda vadība, nevis tās ir atstātas rīku administratoriem.

Biežākās MDR pārraudzības nepilnības, kas jānovērš pirms 2026. gada auditiem

Biežākie trūkumi ir parastas pārvaldības kļūmes.

Pirmkārt, organizācijas aizmirst, ka MDR pakalpojumu sniedzēji var apstrādāt personas datus. Drošības žurnāli dažkārt tiek uzskatīti par “tehniskiem datiem”, bet tie var saturēt personas datus un reizēm arī sensitīvu saturu. GDPR lomu analīze un apstrādātāja klauzulas jānoformē pirms ieviešanas, nevis pārkāpuma laikā.

Otrkārt, žurnālu glabāšana tiek pieņemta kā pašsaprotama, nevis līgumiski noteikta. Ja regulatīvie, kriminālistiskie vai klientu pienākumi prasa pierādījumus vairāku mēnešu garumā, MDR un SIEM glabāšanas modelim tas jāatbalsta. SME politikas prasība par pakalpojumu sniedzēja žurnālu glabāšanu 12 mēnešus ir praktisks pamatlīmenis daudzām vidēm.

Treškārt, trešo pušu piekļuve ir pārāk plaša. Pakalpojumu sniedzēja kontiem jābūt vārdiskiem, aizsargātiem ar MFA, uzraudzītiem, pārskatītiem un, kur iespējams, laikierobežotiem. Koplietoti konti un nepārvaldītas administratīvās sesijas rada audita un incidentu reaģēšanas risku.

Ceturtkārt, incidentu sliekšņi ir neskaidri. MDR smaguma pakāpe automātiski nenozīmē juridisku incidentu, DORA būtisku ar IKT saistītu incidentu, NIS2 nozīmīgu incidentu vai GDPR personas datu aizsardzības pārkāpumu. Rokasgrāmatā jādefinē, kurš pieņem katru lēmumu.

Piektkārt, apakšuzņēmēji ir neredzami. Ja MDR pakalpojumu sniedzējs maina analīzes platformas, atbalsta reģionus vai pakārtotos apstrādātājus, mainās klienta riska aina. Iepriekšēja rakstiska piekrišana un periodiska pārskatīšana ir būtiska.

Sestkārt, pakalpojumu pārskatīšana koncentrējas tikai uz pieteikumu apjomu. Nobriedušas pārskatīšanas izvērtē nokavētus brīdinājumus, regulēšanas izmaiņas, žurnālu avotu darbspēju, pierādījumu izgūšanu, pakalpojumu sniedzēja piekļuvi, sadarbību incidentos un līgumiskos pienākumus.

Nākamie soļi: sagatavojiet savu MDR pakalpojumu sniedzēju auditam ar Clarysec

Ja jūsu MDR pakalpojumu sniedzējs jau darbojas, negaidiet regulatoru, klienta auditoru vai incidentu, lai atklātu, ka jūsu pierādījumi ir nepilnīgi. Sāciet ar vienu nesenu brīdinājumu un izveidojiet izsekojamību. Pēc tam klasificējiet pakalpojumu sniedzēju, pārskatiet līgumu, validējiet žurnālfiksēšanu, testējiet eskalāciju, apstipriniet apstrādātāja klauzulas, pārskatiet piekļuvi un ieplānojiet piegādātāja uzraudzību.

Clarysec var palīdzēt to ātri ieviest praksē, izmantojot:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint pakāpeniskai ieviešanai, tostarp Step 19 žurnālfiksēšanas, uzraudzības un piekļuves validācijai, un Step 23 piegādātāju un incidentu pārvaldības kontroles pasākumiem.
• Zenith Controls: The Cross-Compliance Guide Zenith Controls, lai kartētu ISO/IEC 27002:2022 kontroles pasākumus 5.19, 5.22 un 8.15 pret NIS2, DORA, GDPR, NIST un COBIT audita gaidām.
• Clarysec politiku veidnes, tostarp 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 un Data Protection and Privacy Policy - SME.

MDR ir viens no vērtīgākajiem drošības ieguldījumiem, ko organizācija var veikt. 2026. gadā šī vērtība jāpierāda ar pārvaldību, pierādījumiem un pārskatatbildīgu pārraudzību. Ja vēlaties praktisku MDR pārraudzības pakotni, kas kartēta pret ISO/IEC 27001:2022, NIS2, DORA un GDPR Article 32, Clarysec var palīdzēt to izveidot, pirms nākamais brīdinājums kļūst par nākamo audita konstatējumu.