ISO 27001:n lokitusnäyttö NIS2-, DORA- ja GDPR-auditointeihin

Hälytys saapui SOC:n kanavalle tiistaina kello 2.17: useita epäonnistuneita kirjautumisyrityksiä etuoikeutetulle admin-käyttäjälle uudesta IP-osoitteesta. Yritykset päättyivät muutaman minuutin kuluttua. Nuorempi analyytikko kirjasi hälytyksen, oletti sen johtuvan virheellisesti määritetystä skriptistä tai myöhään työskentelevästä järjestelmänvalvojasta ja siirtyi muihin tehtäviin.

Kaksi päivää myöhemmin nopeasti kasvavan fintech-yhtiön tietoturvajohtaja Maria oli johdon kokouksessa, kun hänen puhelimensa värisi. Tuotekehitystiimi oli havainnut poikkeuksellisen korkean suoritinkuorman tuotantotietokannan instanssissa. Uusi luvaton käyttäjätili oli luotu. Kello 2.17 tullut hälytys ei ollut väärä positiivinen. Se oli ensimmäinen näkyvä merkki tunkeutumisyrityksestä.

Poikkeama saatiin rajattua, mutta tutkinta paljasti suuremman ongelman. Palomuurilokit olivat yhdessä järjestelmässä. Kubernetes-lokit olivat toisessa. Tietokantojen auditointilokit säilytettiin erillään. Useiden aikaleimojen välillä oli minuuttien epäsynkronia. Tiimillä oli lokidataa, mutta se ei pystynyt nopeasti esittämään perusteltua ja todennettavaa kokonaiskuvaa havaitsemisesta, katselmoinnista, eskaloinnista, rajaamisesta ja henkilötietojen tietoturvaloukkauksen arvioinnista.

Marian ISO/IEC 27001:2022 -seuranta-auditointi oli päättynyt hyväksytysti, mutta auditoija jätti yhden varoituksen: organisaatiolla oli lokitus- ja valvontakontrolleja, mutta sen olisi vaikea tuottaa ajoissa korreloitua näyttöä NIS2-, DORA- ja GDPR-raportointipäätöksiä varten.

Tämä on monen organisaation todellisuus vuonna 2026. Niillä ei ole lokitusongelmaa. Niillä on näyttöongelma.

SIEM, EDR-alusta, pilven auditointijälki tai palomuuriloki ei itsessään ole auditointivalmista näyttöä. Näytöstä tulee puolustettavaa vasta, kun sitä ohjataan politiikalla, suojataan peukaloinnilta, katselmoidaan määritellyllä rytmillä, kytketään poikkeamapäätöksiin ja säilytetään riittävän pitkään tapahtumien rekonstruointia varten.

ISO/IEC 27001:2022:n, NIS2:n, DORA:n ja GDPR:n kannalta keskeinen kysymys ei enää ole: ”Keräämmekö lokeja?” Kysymys on: ”Voimmeko osoittaa, mitä tapahtui, kuka katselmoi sen, miten se luokiteltiin, edellyttikö se raportointia ja oliko johdolla asiasta valvontanäkyvyys?”

Miksi lokituksesta ja valvonnasta tuli vaatimustenmukaisuusnäyttöä koskeva kysymys

NIS2, DORA ja GDPR ovat muuttaneet tietoturvalokien liiketoiminnallista merkitystä.

NIS2:n mukaan keskeisten ja tärkeiden toimijoiden tulee toteuttaa asianmukaiset ja oikeasuhteiset kyberturvallisuuden riskienhallintatoimenpiteet. Article 21 sisältää poikkeamien käsittelyn, liiketoiminnan jatkuvuuden, toimitusketjun turvallisuuden, turvallisen kehittämisen, vaikuttavuuden arvioinnin, kyberhygienian, kryptografian, henkilöstöturvallisuuden, pääsynhallinnan, omaisuudenhallinnan, MFA:n ja turvallisen viestinnän. Article 23 luo vaiheistetun raportointimallin, johon sisältyy varhaisvaroitus 24 tunnin kuluessa, poikkeamailmoitus 72 tunnin kuluessa, tarvittaessa väliarvioinnit ja loppuraportti viimeistään kuukauden kuluttua poikkeamailmoituksesta.

Tämä malli perustuu lokitukseen ja valvontaan. Uskottavaa varhaisvaroitusta ei voi lähettää, jos organisaatio ei pysty osoittamaan, milloin tapahtuma havaittiin. Merkittävää poikkeamaa ei voi luokitella, jos vaikutuksen alaisia järjestelmiä, käyttäjätoimintaa, palveluvaikutusta ja rajaamistoimia ei voida rekonstruoida.

DORA kohdistaa samankaltaista painetta finanssialan toimijoihin. Articles 5 to 14 määrittävät hallinnointia ja ICT-riskien hallintaa koskevat odotukset, mukaan lukien hallintoelimen vastuu, ICT-omaisuuden tunnistaminen, suojaus ja ennaltaehkäisy, havaitseminen, reagointi ja toipuminen, varmuuskopiointi, palauttaminen, oppiminen ja viestintä. Articles 17 to 23 edellyttävät ICT:hen liittyvien poikkeamien hallintaprosessia, joka kattaa havaitsemisen, kirjaamisen, luokittelun, eskaloinnin, ilmoittamisen ja jatkotoimet. Articles 24 to 27 käsittelevät digitaalisen toiminnallisen häiriönsietokyvyn testausta. Articles 28 to 31 luovat ICT:n kolmannen osapuolen riskienhallintavelvoitteet.

GDPR lisää tietosuojan osoitusvelvollisuuden kerroksen. Article 32 edellyttää käsittelyn asianmukaista turvallisuutta. Article 33 edellyttää henkilötietojen tietoturvaloukkauksesta ilmoittamista valvontaviranomaiselle ilman aiheetonta viivytystä ja mahdollisuuksien mukaan viimeistään 72 tunnin kuluessa siitä, kun loukkaus on tullut tietoon, ellei loukkauksesta todennäköisesti aiheudu riskiä luonnollisten henkilöiden oikeuksille ja vapauksille. Article 34 voi edellyttää viestintää vaikutuksen kohteena oleville rekisteröidyille, kun riski on korkea. Lokit auttavat määrittämään, onko henkilötietoihin päästy, onko niitä muutettu, onko niitä siirretty luvattomasti tai ovatko ne altistuneet, mutta lokit voivat myös sisältää henkilötietoja, ja niitä tulee hallita sen mukaisesti.

ISO/IEC 27001:2022 tarjoaa hallintajärjestelmän rungon. Clauses 4.1 to 4.4 edellyttävät, että organisaatio ymmärtää toimintaympäristönsä, sidosryhmänsä, vaatimuksensa ja ISMS:n soveltamisalan. Clauses 5.1 to 5.3 edellyttävät johtajuutta, politiikan yhdenmukaisuutta, rooleja, vastuita ja toimivaltaa. Clauses 6.1.1 to 6.1.3 edellyttävät toistettavaa riskien arviointi- ja käsittelyprosessia, mukaan lukien riskikriteerit, riskinomistajat, käsittelyvaihtoehdot, liite A:n kontrollivertailu, soveltuvuuslausunto ja jäännösriskin hyväksyntä. Clause 6.2 edellyttää mitattavia tietoturvatavoitteita.

Siksi lokitus- ja valvontanäyttö ei voi sijaita vain SOC:ssa. Sen paikka on ISMS:ssä, riskirekisterissä, soveltuvuuslausunnossa, tietoturvapoikkeamiin reagoinnin prosessissa, henkilötietojen tietoturvaloukkauksen työnkulussa, toimittajahallinnassa ja johdon raportoinnissa.

ISO 27001 -lokituskontrollit, jotka auditoijat yhdistävät ensin

Teoksessa Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint Controls in Action -vaiheen Step 19: Technological Controls I käsittelee lokitusta, valvontaa ja kellon synkronointia yhtenä näyttöketjuna.

A.8.15 – Lokitus: ”Lokit, jotka tallentavat toimintoja, poikkeuksia, vikoja ja muita olennaisia tapahtumia,
tulee tuottaa, tallentaa, suojata ja analysoida.”

A.8.16 – Valvontatoiminnot: ”Verkkoja, järjestelmiä ja sovelluksia tulee valvoa
poikkeavan käyttäytymisen varalta, ja mahdollisten tietoturvapoikkeamien arvioimiseksi
tulee toteuttaa asianmukaiset toimet.”

A.8.17 – Kellon synkronointi: ”Organisaation käyttämien tietojenkäsittelyjärjestelmien
kellot tulee synkronoida hyväksyttyihin aikalähteisiin.”

Nämä kontrollit vastaavat kolmeen auditointikysymykseen:

Zenith Controls: The Cross-Compliance Guide Zenith Controls tekee yhteyden selväksi:

”Lokitus toimii valvonnan perustavana datakerroksena. Kontrolli 8.16 riippuu kohdassa 8.15 tuotetuista lokeista, jotta tietoturvatapahtumia voidaan analysoida, poikkeamia havaita ja mahdollisia loukkauksia tunnistaa. Ilman kattavaa lokitusta valvontajärjestelmät ovat tehottomia.”

Zenith Controls luokittelee ISO/IEC 27002:2022 -kontrollin 8.15, Lokitus, havaitsevaksi kontrolliksi, joka tukee luottamuksellisuutta, eheyttä ja saatavuutta. Se kartoitetaan Detect-kyberturvallisuuskäsitteeseen ja tietoturvatapahtumien hallintaan. Se yhdistää lokituksen myös valvontatoimintoihin, tietoturvatapahtumien arviointiin ja päätöksentekoon sekä kellon synkronointiin.

Kontrollin 8.16, Valvontatoiminnot, osalta Zenith Controls luokittelee sen havaitsevaksi ja korjaavaksi kontrolliksi, ja se kartoitetaan Detect- ja Respond-alueisiin. Se yhdistää valvonnan toimittajapalvelujen seurantaan ja tapahtumien arviointiin, mikä on olennaista pilvi-, SaaS-, hallittujen palvelujen ja ulkoistusympäristöjen kannalta.

Käytännön viesti on yksinkertainen. Lokit tarjoavat tosiseikat. Valvonta tunnistaa poikkeamat. Kellon synkronointi tekee tosiseikoista luotettavia järjestelmien välillä. Tapahtumien arviointi muuttaa hälytykset päätöksiksi.

Miltä auditointivalmis lokitusnäyttö käytännössä näyttää

Auditointivalmis näyttö ei ole kuvakaappauskansio. Se on yhtenäinen jälki, joka osoittaa kontrollin suunnittelun, kontrollin toiminnan ja päätöksenteon.

Kypsä lokitus- ja valvontanäyttötiedosto sisältää yleensä seuraavat osat:

Clarysecin Enterprise Lokitus- ja valvontapolitiikka Lokitus- ja valvontapolitiikka kuvaa tämän suoraan:

”Tämä politiikka on olennainen ISO/IEC 27001 Clause 8.1:n ja liite A:n kontrollien 8.15 (Lokitus), 8.16 (Valvonta) ja 8.17 (Kellon synkronointi) tukemiseksi, ja se on suoraan kartoitettu GDPR:n, NIS2:n, DORA:n ja COBIT 2019:n mukaisiin sääntelyvelvoitteisiin.”

Kohdasta ”Tarkoitus”, politiikkalauseke 1.3.

Sama politiikka määrittää operatiivisen odotuksen:

”Perustetaan keskitetyt lokitus- ja hälytysjärjestelmät (esim. SIEM), joilla epäilyttävää toimintaa voidaan koota, korreloida ja eskaloida lähes reaaliaikaisesti.”

Kohdasta ”Tavoitteet”, politiikkalauseke 3.4.

Pienemmille organisaatioille Clarysecin pk-yrityksille tarkoitettu Lokitus- ja valvontapolitiikka-sme Lokitus- ja valvontapolitiikka - pk-yritys muuntaa saman periaatteen oikeasuhteisiksi vaatimuksiksi:

”IT-tukipalveluntarjoajan tulee määrittää säännöllinen aikataulu lokien katselmoinnille ja noudattaa sitä:”

Kohdasta ”Hallinnointivaatimukset”, politiikkalauseke 5.1.1.

Se määrittää myös säilytyksen ja suojauksen:

”Lokeja tulee säilyttää vähintään 12 kuukautta, ellei laki tai sopimus edellytä pidempää säilytysaikaa tai ellei pidempi säilytys ole perusteltua aktiivisen poikkeaman tai oikeudellisen riidan vuoksi.”

Kohdasta ”Hallinnointivaatimukset”, politiikkalauseke 5.2.1.

”Lokit tulee tallentaa kirjoitussuojattuihin sijainteihin, ja pääsy tulee rajata vain valtuutetulle henkilöstölle.”

Kohdasta ”Hallinnointivaatimukset”, politiikkalauseke 5.3.1.

NIS2:n ja DORA:n kannalta 12 kuukauden näyttöperustaso voi ratkaista eron uskottavan rekonstruktion ja epäonnistuneen tutkinnan välillä. GDPR:n kannalta se tukee osoitusvelvollisuutta, mutta edellyttää edelleen minimointia, pääsynhallintaa ja säilytyskuria.

Puuttuva silta: tapahtumien arviointi ja raportointikynnykset

Monet organisaatiot keräävät lokeja ja hälyttävät poikkeamista, mutta epäonnistuvat päätöskohdassa.

Oliko hälytys vain tietoturvatapahtuma vai muuttuiko se tietoturvapoikkeamaksi? Oliko se merkittävä NIS2:n mukaan? Oliko se DORA:n mukainen merkittävä ICT:hen liittyvä poikkeama? Oliko henkilötietoja mukana? Edellytetäänkö GDPR:n mukaista henkilötietojen tietoturvaloukkauksen ilmoitusanalyysiä?

Tämä päätöskohta kartoittuu ISO/IEC 27002:2022 -kontrolliin 5.25, tietoturvatapahtumien arviointi ja päätöksenteko. Zenith Controls kuvaa 5.25:tä triage-toimintona raakojen valvontahälytysten ja muodollisen poikkeamien käsittelyn välillä. Se yhdistää 5.25:n poikkeamienhallinnan suunnitteluun, valvontatoimintoihin, tietoturvapoikkeamiin reagointiin ja lokitukseen. Se kartoittaa 5.25:n myös GDPR:n Articles 33 ja 34 -vaatimuksiin tietoturvaloukkauksista ilmoittamisen ja riskien arvioinnin osalta, NIS2:n poikkeamailmoitus- ja luokittelukriteereihin sekä DORA:n merkittävän ICT:hen liittyvän poikkeaman luokitteluun.

Clarysecin Tietoturvapoikkeamien hallintapolitiikka Tietoturvapoikkeamien hallintapolitiikka tukee tätä eskalointikohtaa:

”Jos poikkeama johtaa vahvistettuun tai todennäköiseen henkilötietojen tai muiden sääntelyn alaisten tietojen altistumiseen, lakiasioiden ja DPO:n tulee arvioida seuraavien soveltuvuus:”

Kohdasta ”Politiikan toteutusvaatimukset”, politiikkalauseke 6.4.1.

Pk-yrityksille Tietoturvapoikkeamien hallintapolitiikka-sme Tietoturvapoikkeamien hallintapolitiikka - pk-yritys määrittää teknisen näyttövaatimuksen:

”Lokitusjärjestelmät tulee konfiguroida tallentamaan riittävät tiedot tutkinnan tueksi.”

Kohdasta ”Politiikan toteutusvaatimukset”, politiikkalauseke 6.4.1.

Tässä GDPR Article 33 muuttuu operatiiviseksi. Kysymys ei ole vain siitä, onko henkilötietoihin päästy. Kysymys on siitä, mahdollistavatko lokit, valvontahälytykset ja poikkeamatallenteet DPO:lle oikea-aikaisen ja puolustettavan henkilötietojen tietoturvaloukkauksen arvioinnin.

NIS2 Article 23 ja DORA Articles 17 to 23 luovat samankaltaista painetta. Raportointiajat riippuvat tietoisuudesta, luokittelusta ja olennaisuuden arvioinnista. Organisaation on pystyttävä osoittamaan, milloin hälytys tuotettiin, milloin se katselmoitiin, kuka sen arvioi, mikä päätös tehtiin ja milloin eskalointi tapahtui.

60 minuutin näyttöharjoitus etuoikeutetun kirjautumisen tutkintaan

Hyvä tapa testata näyttövalmiutta on harjoitella todellista skenaariota ennen auditointia tai poikkeamaa.

Skenaario: etuoikeutettu ylläpitäjätili kirjautuu epätavallisesta maasta kello 02.13 UTC. Viisi minuuttia myöhemmin tili yrittää käyttää asiakastietojen vientitoimintoa. Ehdollinen pääsy estää istunnon ja hälytys muodostuu.

Tavoite: tuottaa 60 minuutissa näyttöpaketti, joka osoittaa havaitsemisen, katselmoinnin, eskaloinnin, arvioinnin ja sulkemisen.

Vaihe 1: Vahvista, että tapahtuma löytyy lokeista

Käytä Lokitus- ja valvontapolitiikkaa tarvittavien lokilähteiden tunnistamiseen: identiteetintarjoajan lokit, pilven ylläpitolokit, sovelluslokit, tietokantalokit, päätelaitelokit sekä palomuurin tai suojatun pääsyn lokit.

Vie tapahtumatallenne, jossa näkyvät aikaleima, käyttäjätunnus, lähde-IP, laite, toiminto, tulos ja korrelaatiotunniste. Jos tapahtuma löytyy vain yhdestä konsolista eikä SIEM:stä tai lokien koontiratkaisusta, kirjaa se kontrolliaukoksi.

Zenith Blueprint Step 19 suosittelee varmistamaan, että kriittiset järjestelmät välittävät lokit SIEM:ään tai keskitettyyn lokien koontiratkaisuun, ja validoimaan, että säilytys on politiikan mukaista.

Vaihe 2: Osoita, että valvonta havaitsi sen

Näytä SIEM-hälytys, EDR-hälytys tai identiteettisuojauksen hälytys. Sisällytä säännön nimi, vakavuus, aikaleima, laukaiseva ehto ja ilmoitusreitti. Jos organisaatio käyttää manuaalista katselmointia, näytä päivittäinen raportti ja katselmoijan hyväksyntä.

Enterprise Lokitus- ja valvontapolitiikka tekee tästä roolivastuun:

”Katselmoi päivittäiset raportit ja varmistaa, että poikkeamat analysoidaan, dokumentoidaan ja eskaloidaan tarvittaessa.”

Kohdasta ”Roolit ja vastuut”, politiikkalauseke 4.2.3.

Vaihe 3: Osoita, että eskalointi tapahtui politiikan mukaisessa ajassa

Pk-yrityksille eskalointivaatimus on selkeä:

”Korkean prioriteetin hälytykset tulee eskaloida toimitusjohtajalle ja tietosuojakoordinaattorille 24 tunnin kuluessa.”

Kohdasta ”Soveltaminen ja vaatimustenmukaisuus”, politiikkalauseke 8.1.2.

Yritystiimeillä näyttö voi sisältää poikkeamatiketin, Teams- tai Slack-eskalointitallenteen, hälytyslokin, sähköposti-ilmoituksen, SOC-luovutusmerkinnän tai asianhallintamerkinnän.

Vaihe 4: Luokittele tapahtuma

Käytä Zenith Controls -oppaan 5.25-tapahtuma-arvioinnin logiikkaa. Tallenna, onko hälytys tietoturvatapahtuma, tietoturvapoikkeama, henkilötietojen tietoturvaloukkaus, merkittävä NIS2-poikkeama vai DORA:n mukainen merkittävä ICT:hen liittyvä poikkeama.

Luokittelumerkinnän tulee vastata seuraaviin kysymyksiin:

• Onnistuiko todennus vai estettiinkö se?
• Käytettiinkö etuoikeutettua pääsyä?
• Päästiinkö asiakastietoihin, muutettiinko niitä tai siirrettiinkö niitä luvattomasti?
• Häiriintyivätkö sääntelyn alaiset palvelut?
• Vaikuttiko tapahtuma kriittisiin ICT-omaisuuseriin?
• Ovatko toimittajat tai käsittelijät osallisia?
• Täyttääkö tapahtuma sisäiset raportointikynnykset?
• Edellytetäänkö DPO:n, lakiasioiden, viranomaisen tai asiakkaan ilmoittamista?

Vaihe 5: Rakenna luotettava aikajana

Kellon synkronointi sivuutetaan usein siihen asti, kunnes tutkinta epäonnistuu. Zenith Blueprint Step 19 toteaa, että synkronoitu aika on välttämätön tapahtumien korreloinnille, koska eri järjestelmien lokien on kohdistuttava toisiinsa poikkeama-analyysin aikana.

Sisällytä NTP-konfiguraation näyttö identiteettialustoille, pilvipalveluille, palvelimille, päätelaitteille, tietokannoille, palomuureille ja SIEM:lle. Normalisoi aikaleimat UTC:hen aina kun mahdollista.

Vaihe 6: Sulje tai eskaloi

Jos tapahtuma on rajattu eikä dataan ole päästy, dokumentoi sulkeminen, opit ja ennaltaehkäisevä toimenpide. Jos se muuttuu poikkeamaksi, kytke se tietoturvapoikkeamiin reagointiin, oikeudelliseen arviointiin ja mahdolliseen NIS2-, DORA- tai GDPR-raportoinnin työnkulkuun.

Suojaa lopuksi näyttö. Clarysecin Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka toteaa:

”Kaikki auditointilokit, havainnot ja korjaavien toimenpiteiden raportit tulee säilyttää, salata ja suojata peukaloinnilta.”

Kohdasta ”Soveltaminen ja vaatimustenmukaisuus”, politiikkalauseke 8.5.1.

Tämä yksittäinen harjoitus tuottaa näyttöä liite A.8.15:stä, A.8.16:sta, A.8.17:stä, ISO/IEC 27002:2022 -kontrollista 5.25, GDPR:n mukaisesta henkilötietojen tietoturvaloukkauksen osoitusvelvollisuudesta, NIS2:n poikkeamien käsittelystä ja DORA:n ICT-poikkeaman luokittelusta.

Ristiinvaatimustenmukaisuuden näyttökartta ISO 27001-, NIS2-, DORA- ja GDPR-vaatimuksiin

Vahvimmat vaatimustenmukaisuusohjelmat eivät rakenna erillisiä näyttökokonaisuuksia kullekin viitekehykselle. Ne rakentavat yhden näyttöjärjestelmän, jota voidaan tarkastella useasta auditointinäkökulmasta.

NIST Cybersecurity Framework 2.0 voi auttaa toteuttamaan tämän viestintäkerroksena. Sen kuusi toimintoa, GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND ja RECOVER, osoittavat, että lokitus ja valvonta sijoittuvat pääasiassa DETECT- ja RESPOND-alueille, mutta ne riippuvat hallinnoinnista, omaisuuden ymmärtämisestä ja riskiprioriteeteista.

NIST CSF 2.0 -profiilit voivat myös tukea vuoden 2026 tiekarttaa. Current Profile voi näyttää nykyisen lokituskattavuuden ja hälytysten kypsyystason. Target Profile voi määrittää vaaditun kattavuuden säännellyille järjestelmille, etuoikeutetulle toiminnalle, toimittaja-alustoille ja henkilötietoympäristöille. Niiden välinen ero muodostaa korjaussuunnitelman.

Toimittaja- ja pilvilokit: näyttöaukko, jota auditoijat testaavat yhä useammin

Nykyisissä auditoinneissa vaikeimmat lokituskysymykset liittyvät usein ulkoistettuihin alustoihin.

Pääsettekö pilvipalveluntarjoajanne todennuslokeihin? Lokitetaanko SaaS-ylläpitotoimet? Ovatko tietokantojen auditointilokit käytössä hallituissa palveluissa? Säilyttääkö MSSP hälytyksiä riittävän pitkään? Edellyttävätkö sopimukset yhteistyötä poikkeamatilanteissa? Pystyvätkö toimittajat toimittamaan lokit riittävän nopeasti NIS2:n tai DORA:n raportointiaikatauluja varten? Ovatko käsittelijän lokit saatavilla GDPR:n mukaista henkilötietojen tietoturvaloukkauksen arviointia varten?

Zenith Controls yhdistää valvontatoiminnot, kontrollin 8.16, toimittajapalvelujen seurantaan, kontrolliin 5.22. Se kartoittaa valvonnan myös ISO/IEC 27005:2024 clause 10.5:een, jossa korostetaan riskienkäsittelysuunnitelmien ja kontrollien seurantaa ja katselmointia, sekä ISO/IEC 27035-2:2023 clause 7.3:een, jossa jatkuvan valvonnan mekanismit havaitsevat tietoturvatapahtumia ja käynnistävät poikkeamien hallinnan.

DORA tekee toimittajalokituksesta erityisen tärkeää finanssialan toimijoille, koska ICT:n kolmannen osapuolen riskienhallinta sisältää toimittajarekisterit, sopimusjärjestelyt, alihankintariskin, keskittymäriskin ja exit-strategiat. NIS2 Article 21 sijoittaa toimitusketjun turvallisuuden osaksi kyberturvallisuuden riskienhallintatoimenpiteitä. GDPR voi tehdä toimittajalokeista ratkaisevia, kun käsittelijän poikkeama voi muuttua rekisterinpitäjän ilmoitusvelvollisuuden piiriin kuuluvaksi henkilötietojen tietoturvaloukkaukseksi.

Käytännöllisen toimittajalokitusta koskevan lausekkeen tulisi edellyttää:

• Tietoturvan kannalta olennaiset auditointilokit todennuksesta, käyttöoikeusmuutoksista, ylläpitotoimista, ohjelmointirajapintojen käytöstä, tietojen viennistä ja konfiguraatiomuutoksista.
• Lokien säilytys politiikan, sääntelyvelvoitteiden ja sopimusriskin mukaisesti.
• Aikasynkronointi ja aikavyöhykkeiden normalisointi.
• Peukalointisuojaus ja rajoitettu pääsy lokeihin.
• Poikkeamayhteistyö määritellyissä määräajoissa.
• Näytön toimittaminen auditointeja, tutkintoja ja viranomaistiedusteluja varten.
• Ilmoituslaukaisimet epäilyttävästä pääsystä, palvelun vaarantumisesta tai tietojen altistumisesta.
• Alikäsittelijöiden lokitus- ja eskalointivelvoitteet, kun ne ovat olennaisia.

Toimittajalokitus tulee ratkaista ennen poikkeamaa, ei neuvotella sen aikana.

Miten eri auditoijat testaavat samaa lokituskontrollia

Hyvän näyttöpaketin tulee kestää eri ammatilliset näkökulmat. ISO-auditoija, NIS2-arvioija, DORA-valvoja, GDPR-arvioija sekä COBIT 2019- tai ISACA-suuntautunut auditoija voivat katsoa samaa SIEM-mittaristoa, mutta he kysyvät eri asioita.

Zenith Blueprint Step 19 valmistelee organisaatiot näihin kysymyksiin. Lokituksen osalta auditoijat keskittyvät siihen, lokitetaanko keskeiset tietoturvatapahtumat ja ovatko lokit säilytettyjä, suojattuja ja käyttökelpoisia. Valvontatoimintojen osalta he kysyvät, miten epätavallinen tai luvaton toiminta havaitaan, arvioidaan ja eskaloidaan. Kellon synkronoinnin osalta he voivat verrata aikaleimoja eri järjestelmissä ja merkitä ajan epäsynkronian havainnoksi.

Step 16: People Controls II, kontrolli 6.8, on myös tärkeä, koska poikkeamien ilmoitusmekanismit yhdistävät ihmisten tekemän raportoinnin tekniseen havaitsemiseen. GDPR Article 33, NIS2 Article 23 ja DORA:n poikkeamien raportointivelvoitteet riippuvat kaikki oikea-aikaisesta sisäisestä eskaloinnista.

Yleiset auditointihavainnot ja käytännön korjaukset

Useimmat lokitus- ja valvontahavainnot ovat ennakoitavissa. Ongelma on, että organisaatiot löytävät ne usein vasta auditoinnin aikana eivätkä sisäisessä testauksessa.

Rajallisilla resursseilla toimiville organisaatioille pk-yrityspolitiikan lähestymistapa on realistinen. Se ei edellytä täysimittaista SOC:ia ensimmäisenä päivänä. Se edellyttää määriteltyjä katselmointiaikatauluja, 12 kuukauden säilytystä ellei pidempi aika ole tarpeen, kirjoitussuojattua tallennusta, rajoitettua pääsyä ja korkean prioriteetin hälytysten eskalointia. Tämä luo puolustettavan perustason samalla, kun organisaatio kypsyy kohti keskitettyä SIEM:ää, automatisoitua korrelointia ja hallittua havaitsemista.

Mittarit, jotka tekevät lokituksesta uskottavaa johdolle

Hallitukset ja ylin johto eivät tarvitse raakoja SIEM-tapahtumia. Ne tarvitsevat riskiin liittyvää varmuutta. Koska NIS2 Article 20 ja DORA:n hallinnointivaatimukset asettavat vastuun hallintoelimille, lokitus- ja valvontamittareiden tulisi näkyä tietoturvan hallinnon raportoinnissa.

Hyödyllisiä mittareita ovat:

• Prosenttiosuus kriittisistä omaisuuseristä, jotka välittävät lokit SIEM:ään tai lokien koontiratkaisuun.
• Prosenttiosuus etuoikeutetun pääsyn tapahtumista, jotka ovat hälytysten piirissä.
• SLA:n mukaisesti katselmoitujen korkean prioriteetin hälytysten määrä.
• Keskimääräinen aika hälytyksen tuottamisesta analyytikon katselmointiin.
• Keskimääräinen aika havaitsemisesta eskalointiin.
• Tietoturvapoikkeamiin reagoinnin prosessissa luokiteltujen tapahtumien määrä.
• DPO:n tai lakiasioiden arviointia edellyttävien tapahtumien määrä.
• Lokien säilytyksen vaatimustenmukaisuus järjestelmäluokittain.
• Niiden toimittaja-alustojen määrä, joihin on sopimusperusteinen lokipääsy.
• Niiden järjestelmien määrä, jotka epäonnistuvat kellon synkronoinnin tarkastuksissa.
• Avoimet lokituksen ja valvonnan korjaavat toimenpiteet riskitason mukaan.

Nämä mittarit tukevat ISO/IEC 27001:2022 clause 6.2:n mukaisia mitattavia tietoturvatavoitteita. Ne vahvistavat myös NIS2:n ja DORA:n mukaista johdon valvontaa sekä GDPR:n osoitusvelvollisuutta.

Vuoden 2026 lokitus- ja valvontanäyttöpaketin rakentaminen

Vahva vuoden 2026 näyttöpaketti tulee koota ennen auditointia tai poikkeamaa. Clarysec suosittelee tyypillisesti jäsenneltyä kansiota tai GRC-näyttöobjektia, jossa on seuraavat osiot:

1. Hallinnointi ja soveltamisala: ISMS:n soveltamisala, sidosryhmät, sääntelyn soveltuvuus, johdon hyväksyntä ja roolien nimeämiset.
2. Politiikka: Lokitus- ja valvontapolitiikka, Tietoturvapoikkeamien hallintapolitiikka, Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka, säilytysvaatimukset ja eskalointivaatimukset.
3. Riski ja SoA: riskien arviointi, käsittelysuunnitelma, soveltuvuuslausunnon perustelut A.8.15:lle, A.8.16:lle, A.8.17:lle ja liittyville kontrolleille.
4. Arkkitehtuuri: SIEM- tai lokien koontiratkaisun kaavio, lokilähdeluettelo, pilvilokituksen asetukset ja toimittajalokiriippuvuudet.
5. Kontrollien toiminta: katselmointitallenteet, hälytykset, tiketit, eskalointilokit, sulkemisnäyttö ja poikkeukset.
6. Kytkentä poikkeamiin: tapahtumien luokittelutyölomake, poikkeamarekisteri, DPO:n arviointitallenne ja raportointipäätösloki.
7. Eheys ja säilytys: pääsynhallinta, salaus, kirjoitussuojaus, arkistointiasetukset, poistokontrollit ja säilytysnäyttö.
8. Aikasynkronointi: NTP-konfiguraatio, turvallinen perustaso, kellon poikkeaman seuranta ja UTC-normalisointitapa.
9. Toimittajanäyttö: sopimuslausekkeet, toimittajien varmennusraportit, pilven auditointilokien saatavuus ja poikkeamayhteistyön menettelyt.
10. Parantaminen: sisäisen tarkastuksen havainnot, korjaavien toimenpiteiden seurantataulukko, pöytäharjoitusten tulokset, hälytysten hienosäätötallenteet ja johdon raportit.

Tarkoitus ei ole hukuttaa auditoijia määrään. Tarkoitus on osoittaa, että lokitus ja valvonta toimivat hallittuna prosessina hallinnoinnista havaitsemiseen, arviointiin, eskalointiin, raportointiin ja parantamiseen.

Muuta lokit puolustettavaksi vaatimustenmukaisuusnäytöksi

Marian tiimi ei ratkaissut ongelmaansa ostamalla uutta mittaristoa. Se ratkaisi ongelman muuttamalla lokituksen ja valvonnan näyttömoottoriksi. Politiikat määrittivät vaatimukset. SIEM-säännöt ja pilvilokit tuottivat signaalit. Poikkeamien työnkulut tallensivat päätökset. Kellon synkronointi teki aikajanasta uskottavan. Johdon raportointi teki riskin näkyväksi.

Tätä tasoa organisaatiot tarvitsevat ISO/IEC 27001:2022:n, NIS2:n, DORA:n ja GDPR:n osalta vuonna 2026.

Aloita yhdellä käytännön testillä: ota todellinen hälytys viimeisten 30 päivän ajalta ja osoita päästä päähän, miten se lokitettiin, havaittiin, katselmoitiin, eskaloitiin, luokiteltiin, säilytettiin ja raportoitiin.

Jos vastaus ei ole varma, Clarysec voi auttaa sulkemaan puutteen.

Käytä Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint -opasta Step 19:n toteuttamiseen lokituksen, valvonnan ja kellon synkronoinnin osalta sekä Step 16:n toteuttamiseen poikkeamien ilmoitusmekanismien osalta. Käytä Zenith Controls: The Cross-Compliance Guide Zenith Controls -opasta liite A.8.15:n, A.8.16:n, A.8.17:n ja ISO/IEC 27002:2022 -kontrollin 5.25 kartoittamiseen NIS2-, DORA-, GDPR-, NIST CSF 2.0- ja COBIT 2019 -näkökulmiin.

Vie vaatimukset sen jälkeen käytäntöön Clarysecin Lokitus- ja valvontapolitiikan Lokitus- ja valvontapolitiikka, Lokitus- ja valvontapolitiikka-sme Lokitus- ja valvontapolitiikka - pk-yritys, Tietoturvapoikkeamien hallintapolitiikan Tietoturvapoikkeamien hallintapolitiikka, Tietoturvapoikkeamien hallintapolitiikka-sme Tietoturvapoikkeamien hallintapolitiikka - pk-yritys ja Auditointi- ja vaatimustenmukaisuuden seurantapolitiikan Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka kautta.

Lokit eivät ole näyttöä ennen kuin niitä hallinnoidaan, suojataan, katselmoidaan ja kytketään päätöksiin. Organisaatiot, jotka pystyvät osoittamaan tämän ketjun, läpäisevät auditoinnit nopeammin, reagoivat poikkeamiin paremmin ja antavat johdolle varmuutta, kun seuraava kello 2.17 saapuva hälytys tulee.