MDR-palveluntarjoajan valvonta NIS2:n, DORA:n ja GDPR:n näkökulmasta

Maanantaiaamuna klo 02.13 MDR-palveluntarjoaja avaa vakavan hälytyksen: mahdoton matkustaminen, epäilyttävät postilaatikkosäännöt ja etuoikeutettu tili, jota on käytetty hallitsemattomalta päätelaitteelta. SOC-analyytikko eskaloi asian tikettijärjestelmän kautta. IT-päällikkö nukkuu. Talousjohtaja saa tietojenkalasteluvaroituksen pankkiyhteyshenkilöltä ennen kuin sisäinen poikkeamakanava aktivoituu. Klo 07.30 tietoturvajohtajalla on edessään kolme vaikeaa kysymystä.

Kenellä oli valtuus todeta poikkeama?

Voimmeko osoittaa, että MDR-palveluntarjoajalla oli käytössään oikeat lokit, että niitä säilytettiin riittävän pitkään ja että näyttö säilytettiin asianmukaisesti?

Jos henkilötietoihin on päästy käsiksi, ehtiikö lakitoiminto täyttää GDPR:n mukaiset tietoturvaloukkauksen arvioinnin määräajat samalla, kun operatiivinen toiminto valmistelee NIS2- tai DORA-raportointia?

Kuukautta myöhemmin ulkoinen auditoija pyytää samaa näyttöä eri näkökulmasta. MDR-palveluntarjoajan PDF-raportti on hyödyllinen, mutta se ei riitä. Auditoija haluaa raakahälytystiedot, täydelliset lokitiedostot, eskalointipolun, sisäisen päätöslokin, toimittajakatselmoinnin tallenteen ja näytön siitä, että organisaatio pystyi varmentamaan tapahtumat itsenäisesti.

Tämä on vuoden 2026 MDR-palveluntarjoajan valvonnan ydinhaaste. Organisaatiot ulkoistavat havaitsemisen ja reagoinnin, koska sisäinen SOC-kapasiteetti on kallista, rekrytointi on vaikeaa ja uhkatoiminta on jatkuvaa. Ulkoistettu havaitseminen ei kuitenkaan tarkoita ulkoistettua vastuuta. NIS2:n mukaan hallintoelimet vastaavat edelleen kyberturvallisuuden riskienhallintatoimenpiteiden hyväksymisestä ja valvonnasta. DORA:n mukaan finanssialan toimijat ovat edelleen täysimääräisesti vastuussa ICT-kolmansien osapuolten riskeistä, mukaan lukien kriittiset ICT-palvelut, poikkeamatuki, auditointioikeudet, alihankinta ja irtautuminen. GDPR:n mukaan rekisterinpitäjien on pystyttävä osoittamaan käsittelyn asianmukainen turvallisuus erityisesti silloin, kun henkilötietojen käsittelijät käsittelevät telemetriaa, päätelaitetietoja, käyttäjätunnisteita, IP-osoitteita, sähköpostisisältöä, lokeja tai forensisia levykuvia.

Käytännön puute liittyy harvoin pelkkään MDR-sopimukseen. Se on sopimuksen ja tuotannossa käytettävän palvelun välinen näyttöketju: hälytysten reititys, etuoikeutetut käyttöoikeudet, lokien säilytys, eskalointikynnykset, poikkeamanäyttö, alihankkijoiden läpinäkyvyys, henkilötietojen käsittelijää koskevat lausekkeet, palvelukatselmoinnit, pöytäharjoitukset ja johdon raportointi.

Puolustettavissa oleva MDR-palveluntarjoajan valvontaohjelma tarvitsee yhden toimintamallin, joka kestää useat auditointikeskustelut. ISO/IEC 27001:2022 tarjoaa tähän rungon.

MDR-valvonta alkaa vastuusta, ei SOC-konsolista

Yleinen virhe on käsitellä MDR:n käyttöönottoa teknisenä projektina: otetaan EDR-agentit käyttöön, välitetään identiteettilokit, määritetään hälytykset, sovitaan Teams- tai Slack-kanavasta ja siirrytään tuotantoon. Tämä voi parantaa havaitsemista, mutta se ei osoita hallinnointia.

NIS2 tekee ongelmasta nimenomaisen. Keskeisten ja tärkeiden toimijoiden on toteutettava asianmukaiset ja oikeasuhteiset tekniset, operatiiviset ja organisatoriset kyberturvallisuuden riskienhallintatoimenpiteet. Article 21 sisältää riskianalyysin, poikkeamien käsittelyn, liiketoiminnan jatkuvuuden, toimitusketjun turvallisuuden, kyberhygienian, pääsynhallinnan, omaisuudenhallinnan, kryptografian ja monivaiheisen todennuksen. Article 20 nostaa tämän hallintoelimen vastuuksi ja edellyttää näiden toimenpiteiden hyväksyntää ja valvontaa.

MDR-palveluntarjoajat sijoittuvat usein samanaikaisesti useille NIS2 Article 21 -alueille:

• Poikkeamien käsittely, koska palveluntarjoaja tekee luokittelua, eskaloi ja voi suositella rajaamista.
• Toimitusketjun turvallisuus, koska palveluntarjoaja on suora palveluntarjoaja, jolla on vaikutus operatiiviseen tietoturvaan.
• Pääsynhallinta, koska palveluntarjoaja voi käyttää konsoleita, lokeja, päätelaitetyökaluja tai pilvitenantteja.
• Lokitus ja seuranta, koska havaitseminen riippuu lokien kattavuudesta, säilytyksestä ja korrelaatiosta.
• Kyberhygienia, koska MDR-havainnot paljastavat usein paikkaus-, identiteetti- tai konfiguraatiopuutteita.
• Liiketoiminnan jatkuvuus, koska viivästynyt reagointi voi häiritä kriittisiä palveluja.

Finanssialan toimijoille DORA tiukentaa toimintamallia. DORA:a sovelletaan 17. tammikuuta 2025 alkaen, ja se edellyttää ICT-riskien hallintaa, poikkeamien raportointia, häiriönsietokyvyn testausta, tietojen jakamista ja ICT-kolmansien osapuolten riskien hallintaa. Se myös selventää, että finanssialan toimijoille, jotka on tunnistettu myös NIS2:n mukaisesti, DORA toimii alakohtaisena unionin säädöksenä päällekkäisten kyberturvallisuusvelvoitteiden osalta. Säännelty pankki, maksulaitos, sijoituspalveluyritys, vakuutusyhtiö tai kryptovarapalveluntarjoaja ei voi vain todeta: ”MDR-palveluntarjoajamme hoitaa sen.” DORA edellyttää, että toimija luokittelee ICT-poikkeamat, hallitsee ja seuraa ICT-kolmansien osapuolten palveluntarjoajia, ylläpitää ICT-palvelujärjestelyjen rekistereitä, määrittää sopimusoikeudet, testaa häiriönsietokykyä, tekee juurisyyanalyysin ja raportoi merkittävät ICT:hen liittyvät poikkeamat vaiheittain.

GDPR tuo mukaan toisen näkökulman. Jos MDR-telemetria sisältää käyttäjätunnisteita, IP-osoitteita, sähköpostin metatietoja, todentamistallenteita, päätelaiteartefakteja tai henkilötietoja sisältäviä tiedostoja, GDPR:n tietoturva- ja osoitusvelvollisuusperiaatteita sovelletaan. Article 5 sisältää eheyden, luottamuksellisuuden ja osoitusvelvollisuuden. Article 32:n mukainen käsittelyn turvallisuus muuttuu käytännön näyttökysymykseksi: suojattiinko lokit, rajoitettiinko pääsyä, käytettiinkö salausta tarvittaessa, hallinnoitiinko henkilötietojen käsittelijöitä ja pystyykö organisaatio osoittamaan, mitä tapahtui?

Viesti on kaikissa kolmessa sääntelykokonaisuudessa sama: työn voi delegoida, vastuuta ei.

ISO/IEC 27001:2022 tekee MDR:stä auditoitavan prosessin

Hyvin toteutettu ISO/IEC 27001:2022 -standardiin perustuva ISMS muuttaa MDR-palveluntarjoajan valvonnan toimittajahallinnan lupauksesta näyttöön perustuvaksi toimintamalliksi. Clause 8.1 on erityisen tärkeä, koska se edellyttää, että organisaatiot hallitsevat ISMS:n kannalta olennaisia ulkoisesti tuotettuja prosesseja, tuotteita ja palveluja. MDR on juuri tällainen ulkoisesti tuotettu prosessi, joka voi vaikuttaa tietoturvapoikkeamiin reagointiin, tietosuojaan, häiriönsietokykyyn, sääntelyraportointiin ja liiketoiminnan jatkuvuuteen.

MDR-valvonnan kannalta tärkeimpiä ISO/IEC 27001:2022 Annex A -alueita ovat toimittajasuhteet, toimittajasopimusten tietoturvavaatimukset, ICT-toimitusketjun riskienhallinta, toimittajapalvelujen seuranta, poikkeamien hallinta, näytön käsittely, lokitus, seuranta, pääsynhallinta, etuoikeutettu pääsy, kryptografia ja liiketoiminnan jatkuvuuden valmius.

Clarysecin Zenith Controls: The Cross-Compliance Guide Zenith Controls on tämän työn vaatimustenmukaisuuksia yhdistävä viite. Se kartoittaa ISO/IEC 27002:2022 -hallintakeinot muihin vaatimuksiin, niihin liittyviin hallintakeinoihin, auditointiodotuksiin ja toteutusnäyttöön. MDR-valvonnassa kolme ISO/IEC 27002:2022 -hallintakeinoa ovat keskeisiä: 5.19 toimittajasuhteille, 5.22 toimittajapalvelujen seurannalle ja muutoksenhallinnalle sekä 8.15 lokitukselle. Näitä tukevat 5.20 toimittajasopimukset, 5.21 ICT-toimitusketjun turvallisuus, 5.24–5.28 poikkeamien hallinta ja näytön käsittely, 5.34 tietosuoja ja henkilötiedot, 5.36 vaatimustenmukaisuus, 8.16 seurantatoiminnot, 8.17 kellon synkronointi, 8.18 etuoikeutettujen apuohjelmien käyttö ja 8.8 teknisten haavoittuvuuksien hallinta.

Tällä on merkitystä, koska MDR-auditoinnin epäonnistuminen ei yleensä tarkoita ”ei MDR:ää”. Se tarkoittaa tavallisesti jotakin seuraavista:

• MDR-palveluntarjoajaa ei ollut luokiteltu kriittiseksi.
• Sopimuslausekkeet eivät sisältäneet poikkeamailmoitusta, pääsyä näyttöön tai auditointioikeuksia.
• Lokeja ei säilytetty riittävän pitkään raportoidun tapahtuman tutkimiseksi.
• Palveluntarjoajan pääsy oli jaettu, pysyvä tai valvomaton.
• Asiakas ei katselmoinut MDR-suorituskykyä palvelutasosopimuksiin nähden.
• Alihankkijoita tai alikäsittelijöitä ei ollut hyväksytty.
• Henkilötietojen tietoturvaloukkauksista ilmoittamisen velvoitteita ei ollut sovitettu poikkeamatyönkulkuihin.
• Näyttöä ei säilytetty forensisesti käyttökelpoisella tavalla.
• Johdolla ei ollut mittareita, jotka osoittaisivat, vähensikö MDR-palvelu riskiä.

Zenith Controls kuvaa toimittajaodotusten ja sopimusten välisen suhteen selkeästi:

”5.19 asettaa tietoturvaodotukset sille, miten toimittajien tulee käsitellä organisaation tietoja. 5.20 muotoilee nämä odotukset sopimuksiksi varmistamalla, että sopimukset tai järjestelyt sisältävät nimenomaisesti tietoturvalausekkeita, kuten luottamuksellisuusvaatimuksia, tietoturvapolitiikkojen noudattamista ja poikkeamailmoitusmenettelyjä. Ilman 5.20:tä kohdassa 5.19 tunnistetut vaatimukset eivät välttämättä ole oikeudellisesti täytäntöönpanokelpoisia.”

MDR:n osalta tämä virke on hallinnollinen opetus. Jos sopimus ei velvoita palveluntarjoajaa säilyttämään lokeja, toimittamaan näyttöä, tekemään yhteistyötä poikkeamissa, rajoittamaan alihankintaa, tukemaan auditointeja ja noudattamaan eskalointiaikatauluja, SOC-palvelu voi olla operatiivisesti hyödyllinen mutta auditoinnin näkökulmasta heikko.

Mitä MDR-sopimuksen on osoitettava ennen ensimmäistä hälytystä

Hyvä MDR-sopimus ei ole vain kaupallinen tilauslomake. Se on kontrolliasiakirja. DORA Articles 28 to 30 edellyttävät, että ICT-kolmannen osapuolen riskiä hallitaan koko elinkaaren ajan, mukaan lukien ICT-sopimusten rekisterit, kriittisyysluokittelu, sopimusta edeltävä due diligence, auditointi- ja tarkastusmenettelyt, päättämisoikeudet, irtautumisstrategiat, selkeät palvelukuvaukset, palvelutasot, palvelun ja tietojenkäsittelyn sijainnit, tietosuojasitoumukset, poikkeamatuki ja yhteistyö viranomaisten kanssa. NIS2 Article 21 edellyttää toimitusketjun turvallisuutta suorille toimittajille ja palveluntarjoajille. GDPR edellyttää rekisterinpitäjän ja henkilötietojen käsittelijän rooleja, käsittelijän antamia takeita, tietosuojalausekkeita ja käsittelyn turvallisuutta koskevaa näyttöä.

Clarysecin politiikkakirjasto muuntaa nämä velvoitteet käytännön sopimus- ja toimintavaatimuksiksi. Enterprise Incident Response Policy -politiikassa Tietoturvapoikkeamien hallintapolitiikka MDR käsitellään nimenomaisesti hallittuna kolmannen osapuolen poikkeamakyvykkyytenä:

”Integraatiota kolmannen osapuolen palveluihin, mukaan lukien Managed Detection and Response (MDR), tietoturvapoikkeamien ja -tapahtumien hallinta (SIEM) sekä forensisen analyysin palveluntarjoajat, on hallittava selkeästi määritellyillä palvelutasosopimuksilla (SLA) ja salassapitomääräyksillä.”

Tällä lausekkeella on merkitystä, koska MDR-palveluntarjoajat saavat usein erittäin arkaluonteisia tietoja ennen kuin organisaatio tietää, onko poikkeama raportoitava. Telemetria voi sisältää käyttäjänimiä, tiedostopolkuja, sähköpostin aiheita, sisäisiä isäntänimiä, IP-osoitteita, verkkokaavioita ja vaarantumisen indikaattoreita. Salassapitomääräykset suojaavat organisaatiota tutkinnan aikana ja tukevat GDPR:n mukaista osoitusvelvollisuutta.

Enterprise Third party and supplier security policy Kolmansien osapuolten ja toimittajien tietoturvapolitiikka lisää kaksi lauseketta, joita auditoijat odottavat näkevänsä MDR-valvontaa arvioidessaan:

”Oikeus auditoida, tarkastaa ja pyytää tietoturvanäyttöä”

ja:

”Alihankkijoiden käyttö edellyttää etukäteistä kirjallista suostumusta”

Pk-yrityksissä sama hallinnointiperiaate skaalataan pienemmäksi, mutta sitä ei poisteta. Third-Party and Supplier Security Policy - SME Kolmansien osapuolten ja toimittajien tietoturvapolitiikka - pk-yritys edellyttää vähimmän oikeuden periaatetta:

”Toimittajille on myönnettävä pääsy vain niihin vähimmäisjärjestelmiin ja tietoihin, joita heidän tehtävänsä suorittaminen edellyttää.”

Se edellyttää myös:

”Rajoitukset jatkoalihankinnalle ilman hyväksyntää”

Nämä lausekkeet ovat erityisen olennaisia MDR:n kannalta. Monet palveluntarjoajat käyttävät porrastettuja SOC-tiimejä, alustatoimittajia, uhkatiedustelukumppaneita, pilvianalytiikkapalveluja tai alueellista tukihenkilöstöä. Jos ketjussa alempana olevat osapuolet voivat päästä asiakkaan lokeihin tai henkilötietoihin, asiakas tarvitsee näkyvyyden ja hyväksyntämekanismit. DORA:n näkökulmasta tämä on osa alihankinnan ja keskittymäriskin valvontaa. GDPR:n näkökulmasta kyse on alikäsittelijöiden hallinnasta. NIS2:n näkökulmasta kyse on toimitusketjun riskienhallinnasta.

Keskeinen MDR-valvonnan tarkistuslista

Puolustettavissa olevan MDR-palveluntarjoajasuhteen on oltava testattavissa. Seuraava tarkistuslista yhdistää sopimukselliset, operatiiviset ja näyttövaatimukset yhdeksi kontrollinäkymäksi.

Tämä tarkistuslista tulee sisällyttää hankintaan, käyttöönottoon, säännölliseen katselmointiin ja poikkeamatestaukseen. Jos jokin kohta puuttuu, organisaation tulee käsitellä sitä toimittajariskinä eikä pelkkänä dokumentaatiopuutteena.

Seitsemän näyttöaluetta, joita auditoijat odottavat

Jotta MDR-valvonta on auditointivalmis, Clarysec suosittelee rakentamaan MDR-näyttökansion, joka on järjestetty seitsemään alueeseen. Kansion tulee sijaita ISMS:ssä, ei hankintakansiossa, jota kukaan ei katselmoi.

Tämä taulukko muuttaa keskustelua palveluntarjoajan kanssa. Sen sijaan, että organisaatio kysyy ”Valvotteko meitä?”, se kysyy: ”Voimmeko osoittaa joka neljännes, että MDR-palvelu on edelleen tehokas, vaatimustenmukainen ja riskinottohalukkuutemme mukainen?”

Lokitus on silta havaitsemisen ja vaatimustenmukaisuusnäytön välillä

MDR ilman luotettavaa lokitusta on ulkoistettua arvailua. Palveluntarjoaja voi havaita joitakin uhkia, mutta organisaatio ei pysty osoittamaan laajuutta, aikajanaa, juurisyytä tai vaikutusta.

ISO/IEC 27002:2022 -hallintakeino 8.15 kattaa lokituksen. Zenith Controls luokittelee lokituksen havaitsevaksi kontrolliksi, joka tukee luottamuksellisuutta, eheyttä ja saatavuutta, on linjassa Detect-kyberturvallisuuskonseptin kanssa ja tukee tietoturvatapahtumien hallintakyvykkyyttä. Se kytkee lokituksen suoraan seurantatoimintoihin, tapahtumien arviointiin, tietoturvapoikkeamiin reagointiin, opittuihin asioihin, etuoikeutettuun pääsyyn, kellon synkronointiin, pääsynhallintaan, tietosuojaan, todisteiden keräämiseen, haavoittuvuuksien hallintaan ja fyysisen turvallisuuden valvontaan.

Siksi lokitus on keskeinen NIS2:n, DORA:n ja GDPR Article 32:n näytössä. NIS2 Article 23:n mukainen merkittävien poikkeamien raportointi edellyttää varhaisvaroitusta 24 tunnin kuluessa tietoisuudesta, ilmoitusta 72 tunnin kuluessa ja loppuraporttia viimeistään kuukauden kuluttua ilmoituksesta. DORA:n mukainen merkittävien ICT:hen liittyvien poikkeamien raportointi edellyttää luokittelua, eskalointia, viestintää, juurisyyanalyysiä ja loppuraportointia. GDPR:n osoitusvelvollisuus edellyttää, että organisaatiot osoittavat, mitä henkilötiedoille tapahtui ja olivatko tietoturvatoimenpiteet asianmukaisia.

Clarysecin Logging and Monitoring Policy - SME Lokitus- ja valvontapolitiikka - pk-yritys tarjoaa yksinkertaisen sopimuksellisen kontrollin pienemmille organisaatioille, jotka käyttävät ulkoisia palveluntarjoajia:

”Sopimusten on edellytettävä, että palveluntarjoajat säilyttävät lokit vähintään 12 kuukauden ajan ja antavat pääsyn niihin pyynnöstä”

Yritysympäristöissä Logging and Monitoring Policy Lokitus- ja valvontapolitiikka lisää operatiivisen integraatiovaatimuksen:

”Lokitiedot on toimitettava pyynnöstä tai integroitava organisaation SIEM-/lokien koontialustaan.”

Nämä lausekkeet ratkaisevat toistuvan tietoturvapoikkeamiin reagoinnin ongelman: tutkinnan aikana MDR-palveluntarjoaja toteaa, että tapahtuma on vanhempi kuin haettavissa oleva säilytysikkuna, lokit ovat saatavilla vain maksullisena forensisena vientinä tai asiakkaan SIEM ei sisällä palveluntarjoajan rikastuksia ja analyytikkotoimia. Jos pääsyä lokeihin ei määritellä etukäteen, poikkeaman aikajana pirstoutuu.

Vahvassa MDR-lokitusmallissa on määriteltävä pakolliset lokilähteet, tapahtumatyypit, säilytysajat, eheyden suojaus, pääsyn hyväksynnät, aikasynkronointi, vientimuodot ja korrelointisäännöt asiakkaan ja palveluntarjoajan alustojen välillä. Sen tulee kattaa myös palveluntarjoajan toimet, mukaan lukien havaitsemissääntöjen muutokset, päätelaitteen eristyskomennot, ylläpidollinen pääsy, analyytikon muistiinpanot ja näytön viennit.

ISO:n tukistandardit vahvistavat tämän lähestymistavan. ISO/IEC 27035-1:2023 ja ISO/IEC 27035-2:2023 kytkevät lokituksen poikkeamien havaitsemiseen, triageen ja keskitettyyn analyysiin. ISO/IEC 27701:2021 lisää henkilötietojen käsittelytoimien tietosuojakohtaisen lokituksen. ISO/IEC 27017:2021 ja ISO/IEC 27018:2020 lisäävät pilviympäristöjen ja pilvessä käsiteltävien henkilötietojen lokitusodotukset erityisesti silloin, kun palveluntarjoajat käsittelevät asiakastietoja julkisissa pilviympäristöissä. ISO/IEC 27005:2024 jäsentää riittämättömän lokituksen riskien käsittelyn kysymykseksi, ei pelkäksi työkalupuutteeksi.

Tietoturvapoikkeamiin reagointi: MDR voi eskaloida, mutta johdon on päätettävä

MDR-palveluntarjoajat havaitsevat ja neuvovat. Vastuuorganisaatio toteaa poikkeamat, arvioi sääntelyvaikutukset, viestii viranomaisten kanssa ja päättää, edellyttääkö henkilötietojen tietoturvaloukkaus ilmoittamista.

Tällä erottelulla on merkitystä, koska MDR-vakavuus ei automaattisesti tarkoita NIS2:n mukaista merkittävää poikkeamaa, DORA:n mukaista merkittävää ICT:hen liittyvää poikkeamaa tai GDPR:n mukaista henkilötietojen tietoturvaloukkausta. Palveluntarjoaja voi merkitä hälytyksen ”vakavaksi”, mutta organisaation on päätettävä, vaikuttivatko tapahtumat kriittisiin palveluihin, vaarantuivatko henkilötiedot, onko asiakkaille ilmoitettava, onko viranomaisille ilmoitettava ja onko johdon hyväksyttävä operatiivisesti vaikuttava rajaamistoimi.

Clarysecin Incident Response Policy - SME Tietoturvapoikkeamien hallintapolitiikka - pk-yritys on suora:

”Kolmansien osapuolten on toimittava allekirjoitettujen sopimusten mukaisesti, ja sopimusten on sisällettävä henkilötietojen tietoturvaloukkausten ilmoituslausekkeet ja yhteistyöhön perustuvat reagointivelvoitteet.”

Tässä lausekkeessa GDPR Article 32:n näyttö kohtaa operatiivisen tietoturvapoikkeamiin reagoinnin. Jos MDR-palveluntarjoaja havaitsee epäillyn tietojen luvattoman siirron päätelaitteelta, joka sisältää henkilötietoja, palveluntarjoajan on tiedettävä, kuinka nopeasti ilmoitetaan, kenelle ilmoitetaan, mitä näyttöä säilytetään ja miten rekisterinpitäjän arviointia tuetaan.

Clarysecin Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint antaa testausmenetelmän. Controls in Action -vaiheessa Step 19 Zenith Blueprint ohjeistaa tiimejä validoimaan lokituksen ja seurannan operatiivisesti:

”Valitse viimeaikainen poikkeama tai tapahtuma ja osoita, miten jäljitit sen lokien avulla. Jos lokien eheysominaisuuksia, kuten tiivisteen tarkistusta, käytetään, dokumentoi myös se. Varmista, että hälyttäminen toimii, esimerkiksi että epäonnistuneet kirjautumiset tai käyttöoikeuksien korotukset laukaisevat hälytykset.”

Sama vaihe käsittelee identiteettiä ja etuoikeutettua pääsyä:

”Varmista etuoikeutettujen tilien osalta, että MFA on pakotettu käyttöön, ylläpitäjäroolit on eriytetty (admin_john-tyylisiä tilejä käytetään vain ylläpitotehtäviin) ja ajantasainen luettelo etuoikeutetuista käyttäjistä on olemassa.”

MDR-kontekstissa etuoikeutettujen käyttäjien luettelon on sisällettävä myös palveluntarjoajan tilit, ei vain työntekijöitä. Jos MDR-palveluntarjoajalla on pääsy konsoliin, päätelaitteiden eristysoikeudet, EDR-ylläpito-oikeudet tai lukuoikeus arkaluonteisiin lokeihin, nämä tilit kuuluvat katselmointiin.

Zenith Blueprint -oppaan Step 23 antaa tämän jälkeen poikkeama- ja toimittajatestauksen rakenteen:

”Valitse viimeaikainen tapahtuma tai toteuta pöytäharjoitus suunnitelman validoimiseksi. Tallenna ja kirjaa lokiin kaikki päätökset, roolit ja viestintä (5.26) ja päivitä suunnitelma opittujen asioiden perusteella (5.27). Varmista, että käytössä on menettelyt forensisen todistusaineiston säilyttämiseksi (5.28), mukaan lukien lokitilannevedokset, varmuuskopiot ja vaikutuksen kohteena olevien järjestelmien turvallinen eristäminen.”

Realistisen pöytäharjoituksen tulee sisältää MDR-palveluntarjoaja. Käytä skenaariota, kuten vaarantunut etuoikeutettu tili, päätelaitteen eristäminen, epäilty postilaatikon käyttö, mahdollinen palkkahallinnon tietojen altistuminen ja hälytyksen eskalointi työajan ulkopuolella. Testin tulee varmistaa, alkaako MDR-palveluntarjoajan kello havaitsemisesta, asiakkaan ilmoittamisesta vai asiakkaan kuittauksesta. Tällä erolla on merkitystä, kun sääntelyaikataulut riippuvat tietoisuudesta ja päätöspisteistä.

Rakenna yhden hälytyksen MDR-valvontapaketti 90 minuutissa

Nopea tapa paljastaa puutteet on valita yksi viimeaikainen vakava MDR-hälytys ja rakentaa siitä yhden sivun näyttöjälki. Tämä käytännön harjoitus toimii hyvin ennen auditointeja, hallituksen katselmointeja ja sopimusten uusimista.

1. Aloita hälytystiketistä. Tallenna aikaleima, havaitsemissääntö, vaikutuksen kohteena oleva omaisuuserä, käyttäjä, vakavuus, MDR-analyytikon muistiinpanot ja eskalointipolku.
2. Hae sopimuslauseke tai palvelutasosopimus, joka osoittaa kyseiselle vakavuudelle odotetun vasteajan.
3. Hae lokilähdeluettelo, joka osoittaa, mitkä järjestelmät tuottivat hälytyksen, kuten EDR, identiteetin tarjoaja, palomuuri, sähköpostin suojausyhdyskäytävä ja pilvipohjaiset auditointilokit.
4. Vahvista, että lokit säilytetään politiikan mukaisesti ja että historiallinen tapahtuma on edelleen haettavissa.
5. Varmista, käyttikö MDR-analyytikko mitään asiakkaan ympäristöä. Jos käytti, tallenna nimetty tili, MFA-näyttö, istuntolokit ja hyväksyntä.
6. Dokumentoi asiakkaan puolen päätös: tapahtuma suljettiin, poikkeama todettiin, oikeudellinen arviointi käynnistettiin, rajaaminen tehtiin tai riski hyväksyttiin.
7. Jos henkilötiedot voivat olla mukana, kirjaa GDPR-roolianalyysi, tietoturvaloukkauksen arvioinnin omistaja ja käynnistyivätkö henkilötietojen käsittelijän ilmoitusvelvoitteet.
8. Päätä opittuihin asioihin: viritys, uusi havaitsemissääntö, käyttöoikeusmuutos, pelikirjan päivitys tai toimittajan palvelutasosopimukseen liittyvä ongelma.

Tämä yhden hälytyksen jälki on tehokas, koska se yhdistää sopimuksen, lokituksen, pääsyn, tietoturvapoikkeamiin reagoinnin, tietosuojan ja johdon valvonnan yhdeksi näyttöketjuksi. Jos et pysty rakentamaan sitä viimeaikaisesta hälytyksestä, et todennäköisesti pysty rakentamaan sitä sääntelypaineen alla.

Toimittajien seuranta on kohta, jossa useimmat MDR-ohjelmat heikkenevät

Monet organisaatiot tekevät due diligence -arvioinnin ennen MDR-sopimuksen allekirjoittamista ja lopettavat siihen. Se ei riitä ISO/IEC 27001:2022:n, NIS2:n, DORA:n tai GDPR:n kannalta. MDR-palvelut muuttuvat jatkuvasti: uusia havaitsemissääntöjä, uusia analyytikkotiimejä, uusia alikäsittelijöitä, uusia datasijainteja, uusia EDR-kyvykkyyksiä, uusia integraatioita, uusia uhkatiedustelusyötteitä ja uusia tukimalleja.

ISO/IEC 27002:2022 -hallintakeino 5.22 käsittelee toimittajapalvelujen seurantaa, katselmointia ja muutoksenhallintaa. Zenith Controls selittää, että 5.22 rakentuu toimittajasuhteiden ja sopimusten hallintakeinojen varaan varmistamalla jatkuvan seurannan ja hallinnan palvelun käynnistämisen jälkeen. Se liittyy häiriötilanteiden aikaiseen turvallisuuteen, haavoittuvuuksien hallintaan, vaatimustenmukaisuuteen, pääsynhallintaan ja turvalliseen suunnitteluun.

DORA Articles 28 to 30 tekevät tästä erityisen tärkeää finanssialan toimijoille. Ne edellyttävät jatkuvaa seurantaa, ICT-kolmannen osapuolen järjestelyjen rekistereitä, kriittisyyserotteluja, due diligence -menettelyjä, auditointi- ja tarkastusoikeuksia, päättämisoikeuksia, irtautumisstrategioita, palvelutasoja, poikkeamatukea, yhteistyötä viranomaisten kanssa sekä kriittisille tai tärkeille toiminnoille palvelutavoitteita, varautumistestausta ja tarvittaessa uhkalähtöiseen penetraatiotestaukseen liittyvää yhteistyötä.

Zenith Blueprint, Controls in Action -vaihe, Step 23, antaa toimittajan elinkaaren rakenteen:

”Kokoa täydellinen luettelo nykyisistä toimittajista ja palveluntarjoajista (5.19) ja luokittele ne järjestelmiin, tietoihin tai operatiiviseen ohjaukseen kohdistuvan pääsyn perusteella.”

Se jatkaa:

”Tunnista jokaisen kriittisen toimittajan osalta, käyttävätkö he alihankkijoita (alikäsittelijöitä), jotka voivat päästä tietoihisi tai järjestelmiisi.”

Käytännöllinen MDR-palvelukatselmointi tulee pitää kriittisissä ympäristöissä neljännesvuosittain ja vähäriskisemmissä ympäristöissä vähintään vuosittain. Esityslistan tulee sisältää SLA-vaatimustenmukaisuus vakavuuden mukaan, eskaloidut hälytykset, todelliset positiiviset havainnot, väärät positiiviset havainnot, ohitetut eskaloinnit, lokilähteiden toimintakunto, etuoikeutettujen käyttöoikeuksien muutokset, uudet integraatiot, uudet alueet, alihankkijat, alikäsittelijät, havaitsemissääntöjen muutokset, poikkeamatuen suorituskyky, näyttöpyynnöt, avoimet riskit, korjaavat toimenpiteet ja irtautumisvalmius.

Tämä ei ole mikromanagerointia. Se on varmistussilmukka, joka osoittaa, että organisaatio hallinnoi aktiivisesti kriittistä tietoturvatoimittajaa.

Vaatimustenmukaisuuksien välinen kartoitus: yksi MDR-kontrollijoukko, viisi auditointikeskustelua

ISO/IEC 27001:2022:n arvo on siinä, että se antaa organisaatioille yhden johdonmukaisen ISMS-syklin useisiin vaatimustenmukaisuuskeskusteluihin. Sama MDR-valvonnan näyttöpaketti voidaan kartoittaa NIS2:n, DORA:n, GDPR:n, NIST CSF 2.0:n ja COBIT 2019:n mukaisesti.

NIST CSF 2.0 on hyödyllinen viestinnässä. Sen GOVERN-toiminto edellyttää, että lakisääteiset, sääntelyyn perustuvat, sopimukselliset ja tietosuojaan liittyvät velvoitteet ymmärretään ja niitä hallitaan, roolit ja toimivaltuudet määritellään, kyberturvallisuusriski integroidaan yrityksen riskienhallintaan ja toimittajariskeistä viestitään ja niitä seurataan.

COBIT 2019 on hyödyllinen johtamisen ja varmennuksen kannalta. COBIT-suuntautuneet auditoijat keskittyvät usein vähemmän yksittäiseen hallintakeinoon ja enemmän siihen, toimivatko hallinnointitavoitteet, palvelunhallinta, riskinomistajuus ja suorituskyvyn seuranta järjestelmänä.

Miten auditoijat testaavat MDR-palveluntarjoajan valvontaa

Eri auditoijat käyttävät eri näkökulmia, mutta he kaikki haluavat näyttöä siitä, että organisaatio hallitsee suhdetta.

ISO/IEC 27001:2022 -auditoija aloittaa soveltamisalasta, sidosryhmistä, riskien arvioinnista, soveltuvuuslausunnosta, riskienkäsittelysuunnitelmasta ja operatiivisesta näytöstä. Jos MDR kuuluu soveltamisalaan, auditoija odottaa, että ulkoisesti tuotettuja prosesseja hallitaan ISMS:n mukaisesti. Hän voi poimia näytteitä toimittajasuhteista, toimittajasopimuksista, toimittajapalvelujen seurannasta, lokituksesta, seurannasta, tietoturvapoikkeamiin reagoinnista, näytön käsittelystä ja pääsynhallinnasta.

DORA-valvoja keskittyy operatiiviseen häiriönsietokykyyn ja järjestelmätason riskiin. Hän voi tarkastella kriittisyysarviointia, ICT-palvelurekisteriä, keskittymäriskianalyysiä, irtautumisstrategiaa, poikkeamien luokittelua, auditointioikeuksia ja näyttöä siitä, että MDR-palveluntarjoaja pystyy tukemaan sääntelyraportointia.

GDPR-auditoija tai tietosuojakatselmoija keskittyy rekisterinpitäjä–henkilötietojen käsittelijä -hallinnointiin. Hän pyytää tietojenkäsittelysopimusta, henkilötietojen käsittelijää koskevaa due diligence -arviointia, alikäsittelijöiden kontrolleja, henkilötietoja sisältävien lokien suojatoimia, säilytyskontrolleja, tietoturvaloukkauksen arviointitallenteita ja Article 32:a tukevaa näyttöä.

COBIT- tai ISACA-auditoija tarkastaa hallinnointinäytön: toimittajariskin omistajuuden, hankintatyönkulun, palvelukatselmointien pöytäkirjat, SLA-poikkeamien seurannan, korjaavat toimenpiteet, näytön laadun ja sen, saako johto merkityksellisiä mittareita.

Paljastavin auditointipyyntö on yksinkertainen: ”Näytä yksi MDR-hälytys havaitsemisesta sulkemiseen.” Jos pystyt osoittamaan sopimusodotuksen, lokilähteen, hälytyksen, eskaloinnin, päätöksen, näytön säilyttämisen, tietosuoja-arvioinnin, korjaavat toimet ja johdon raportoinnin, MDR-valvontasi on kypsä. Jos pystyt näyttämään vain toimittajan tiketin, sinulla on seurantaa mutta heikko hallinnointi.

Johdon raportointi: hallitus ei tarvitse pakettikaappauksia

NIS2 ja DORA asettavat molemmat vastuun hallintoelimen tasolle. Hallitukset ja ylin johto eivät tarvitse raakatelemetriaa. Ne tarvitsevat riskin kannalta olennaisia MDR-valvonnan mittareita.

Hyödyllinen neljännesvuosittainen MDR-mittaristo sisältää:

• Käyttöönotetut kriittiset lokilähteet suhteessa odotettuihin lokilähteisiin.
• MDR:n kattamien kriittisten omaisuuserien prosenttiosuus.
• Vakavat hälytykset luokan ja liiketoimintapalvelun mukaan.
• Keskimääräinen aika havaitsemisesta asiakkaalle ilmoittamiseen.
• Keskimääräinen aika asiakkaan kuittauksesta päätökseen.
• SLA-rikkomukset ja avoimet palveluntarjoajan toimet.
• Etuoikeutettujen palveluntarjoajatilien katselmointitila.
• Alihankkijoiden tai alikäsittelijöiden muutokset.
• Poikkeamat, jotka edellyttävät oikeudellista, sääntelyyn liittyvää tai asiakkaille ilmoittamista koskevaa arviointia.
• Toteutetut opitut asiat.

Tämän mittariston tulee syöttää ISMS:n johdon katselmointia, riskien käsittelyn päivityksiä ja toimittajakatselmointia. ISO/IEC 27001:2022:n mukaan johdon on varmistettava, että ISMS on linjassa strategisen suunnan kanssa, resurssit ovat käytettävissä, vastuut on osoitettu, viestintä toimii ja jatkuva parantaminen toteutuu. MDR-mittarit ovat käytännöllinen tapa osoittaa, että ulkoistettuja tietoturvaoperaatioita hallinnoi johto eikä niitä jätetä työkalujen ylläpitäjille.

Yleiset MDR-valvonnan sudenkuopat, jotka on korjattava ennen vuoden 2026 auditointeja

Yleisimmät puutteet ovat tavallisia hallinnointivirheitä.

Ensinnäkin organisaatiot unohtavat, että MDR-palveluntarjoajat voivat käsitellä henkilötietoja. Tietoturvalokeja käsitellään toisinaan ”teknisinä tietoina”, mutta ne voivat sisältää henkilötietoja ja ajoittain arkaluonteista sisältöä. GDPR-roolianalyysi ja henkilötietojen käsittelijää koskevat lausekkeet tulee tehdä ennen käyttöönottoa, ei tietoturvaloukkauksen aikana.

Toiseksi lokien säilytystä oletetaan sen sijaan, että siitä sovitaan. Jos sääntely-, forensiikka- tai asiakasvelvoitteet edellyttävät näyttöä kuukausien ajalta, MDR- ja SIEM-säilytysmallin on tuettava sitä. Pk-yrityspolitiikan vaatimus palveluntarjoajan lokien 12 kuukauden säilytyksestä on käytännöllinen perustaso monille ympäristöille.

Kolmanneksi kolmannen osapuolen pääsy on liian laaja. Palveluntarjoajan tilien tulee olla nimettyjä, MFA-suojattuja, valvottuja, katselmoituja ja mahdollisuuksien mukaan aikarajoitettuja. Jaetut tunnukset ja hallitsemattomat ylläpitoistunnot luovat auditointi- ja tietoturvapoikkeamiin reagoinnin riskiä.

Neljänneksi poikkeamakynnykset ovat epäselviä. MDR-vakavuus ei automaattisesti tarkoita oikeudellista poikkeamaa, DORA:n mukaista merkittävää ICT:hen liittyvää poikkeamaa, NIS2:n mukaista merkittävää poikkeamaa tai GDPR:n mukaista henkilötietojen tietoturvaloukkausta. Pelikirjan on määriteltävä, kuka tekee kunkin päätöksen.

Viidenneksi alihankkijat ovat näkymättömiä. Jos MDR-palveluntarjoaja vaihtaa analyysialustoja, tukialueita tai ketjussa alempana olevia käsittelijöitä, asiakkaan riskikuva muuttuu. Etukäteinen kirjallinen suostumus ja säännöllinen katselmointi ovat välttämättömiä.

Kuudenneksi palvelukatselmoinnit keskittyvät vain tikettimäärään. Kypsät katselmoinnit tarkastelevat havaitsematta jääneitä hälytyksiä, viritysmuutoksia, lokilähteiden toimintakuntoa, näytön hakua, palveluntarjoajan pääsyä, poikkeamayhteistyötä ja sopimusvelvoitteita.

Seuraavat vaiheet: tee MDR-palveluntarjoajastasi auditointivalmis Clarysecin avulla

Jos MDR-palveluntarjoajasi on jo käytössä, älä odota, että viranomainen, asiakkaan auditoija tai poikkeama paljastaa näytön puutteellisuuden. Aloita yhdestä viimeaikaisesta hälytyksestä ja rakenna jälki. Luokittele sitten palveluntarjoaja, katselmoi sopimus, validoi lokitus, testaa eskalointi, vahvista henkilötietojen käsittelijää koskevat lausekkeet, katselmoi pääsy ja aikatauluta toimittajien seuranta.

Clarysec voi auttaa toteuttamaan tämän nopeasti seuraavilla välineillä:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint vaiheittaiseen toteutukseen, mukaan lukien Step 19 lokituksen, seurannan ja käyttöoikeuksien validointiin sekä Step 23 toimittaja- ja poikkeamanhallinnan kontrolleihin.
• Zenith Controls: The Cross-Compliance Guide Zenith Controls ISO/IEC 27002:2022 -hallintakeinojen 5.19, 5.22 ja 8.15 kartoittamiseen NIS2:n, DORA:n, GDPR:n, NIST:n ja COBIT:n auditointiodotuksiin.
• Clarysecin politiikkamallit, mukaan lukien Tietoturvapoikkeamien hallintapolitiikka, Kolmansien osapuolten ja toimittajien tietoturvapolitiikka, Lokitus- ja valvontapolitiikka, Tietoturvapoikkeamien hallintapolitiikka - pk-yritys, Kolmansien osapuolten ja toimittajien tietoturvapolitiikka - pk-yritys, Lokitus- ja valvontapolitiikka - pk-yritys ja Tietosuoja- ja yksityisyydensuojapolitiikka - pk-yritys.

MDR on yksi arvokkaimmista tietoturvainvestoinneista, joita organisaatio voi tehdä. Vuonna 2026 tämä arvo on osoitettava hallinnolla, näytöllä ja vastuullisella valvonnalla. Jos haluat käytännöllisen MDR-valvontapaketin, joka on kartoitettu ISO/IEC 27001:2022:n, NIS2:n, DORA:n ja GDPR Article 32:n mukaisesti, Clarysec voi auttaa rakentamaan sen ennen kuin seuraavasta hälytyksestä tulee seuraava auditointihavainto.