Henkilötiedot tietoturvalokeissa: GDPR-, NIS2- ja DORA-pelikirja

Tietoturva-analyytikko avaa SIEM-järjestelmän klo 02.17. Hälytys näyttää aluksi tavanomaiselta: useita epäonnistuneita kirjautumisia, onnistunut istunto epätavallisesta IP-osoitteesta ja sen jälkeen nopea sarja API-kutsuja asiakkaan vientirajapintaa vasten. Muutamassa minuutissa poikkeamakanava täyttyy viesteistä. Tietoturvajohtaja haluaa tietää, onko kyseessä käyttäjätilin haltuunotto. Lakiasiat kysyy, sisältävätkö lokit henkilötietoja. Tietosuojavastaava kysyy, kattavatko tietosuojaseloste ja seloste käsittelytoimista SIEM-järjestelmässä olevat käyttäjätunnukset, IP-osoitteet, laitetunnisteet ja pyyntöjen URL-osoitteet. Vaatimustenmukaisuuspäällikkö kysyy, onko lokit säilytettävä sääntelyraportointia varten. Asiakastiimi kysyy, voiko asiakas pyytää samojen lokimerkintöjen poistamista huomenna.

Tässä kohdassa moni organisaatio huomaa, että tietoturvalokitus ja tietosuojan hallinta on rakennettu erillisiksi maailmoiksi.

Tietoturvatiimit tarvitsevat yksityiskohtaisia lokeja, pitkää säilytystä, muuttumatonta tallennusta ja nopeaa pääsyä. Tietosuojatiimit edellyttävät minimointia, käyttötarkoitussidonnaisuutta, roolipohjaista pääsyä, kurinalaista säilytystä ja poistamista, kun tietoja ei enää tarvita. Poikkeamiin reagoivat tiimit haluavat säilyttää todentavan aineiston täsmälleen sellaisena kuin se oli. GDPR:n mukainen osoitusvelvollisuus edellyttää, että organisaatio pystyy perustelemaan, miksi henkilötiedot ovat lokeissa, kuka on käyttänyt niitä ja kuinka kauan niitä säilytetään. NIS2 ja DORA lisäävät kiireellisyyttä, koska keskeisillä toimijoilla, tärkeillä toimijoilla ja finanssialan organisaatioilla on oltava riittävästi todentavaa aineistoa poikkeamien luokitteluun, oikea-aikaiseen raportointiin ja tehokkaan ICT-riskien hallinnan osoittamiseen.

Epämukava tosiasia on yksinkertainen: tietoturvalokit ovat usein henkilötietojen tietovarastoja. Todennuslokit voivat sisältää käyttäjänimiä, sähköpostiosoitteita, IP-osoitteita, laitteen sormenjälkiä ja geopaikannustietoja. Sovelluslokit voivat paljastaa URL-osoitteita, hakumerkkijonoja, hyötykuorman osia, asianumeroita ja viestisisältöä. EDR- ja pilvilokit voivat sisältää työntekijöihin yhdistettäviä isäntänimiä, nimiä sisältäviä tiedostopolkuja, istuntotunnisteita ja ylläpitäjien toimia. IAM-lokit voivat paljastaa käyttöoikeusmuutoksia, ryhmäjäsenyyksiä ja epäonnistuneita pääsyyrityksiä arkaluonteisiin järjestelmiin.

Jos lokit sisältävät henkilötietoja, kyse ei ole enää vain ISO 27001 -lokitusasiasta. Siitä tulee tietosuojaa, säilytystä, todentavaa aineistoa, poikkeamien raportointia ja toimittajahallintaa koskeva kysymys. Clarysec käsittelee henkilötietoja sisältävien tietoturvalokien hallintaa vaatimustenmukaisuuden osa-alueet ylittävänä ongelmana, ei työkalun konfigurointiongelmana.

Tietoturvajohtajan todellinen dilemma: havaitsemisnäyttö vai tietojen minimointi

Klo 02.17 -skenaariossa tietoturvajohtajalla on edessään todellinen operatiivinen ristiriita. Jos lokit ovat liian niukkoja, SOC ei pysty havaitsemaan vaarantumista, rekonstruoimaan aikajanoja tai tukemaan NIS2- ja DORA-raportointia. Jos lokit ovat liian runsaita, organisaatio voi kerätä tarpeettoman paljon henkilötietoja, säilyttää niitä liian pitkään, altistaa niitä liian monelle ylläpitäjälle tai epäonnistua GDPR:n mukaisten oikeuksien ja läpinäkyvyysvelvoitteiden tukemisessa.

GDPR määrittelee henkilötiedot laajasti tiedoiksi, jotka liittyvät tunnistettuun tai tunnistettavissa olevaan henkilöön. Käsittely kattaa keräämisen, säilyttämisen, käytön, luovuttamisen, poistamisen ja tuhoamisen. Käytännössä IP-osoitteita, käyttäjätunnuksia, laitetunnisteita tai toimintalokeja sisältävät lokit voivat asiayhteydestä riippuen olla henkilötietoja. GDPR:n periaatteet edellyttävät lainmukaista, kohtuullista ja läpinäkyvää käsittelyä, käyttötarkoitussidonnaisuutta, tietojen minimointia, säilytyksen rajoittamista, eheyttä ja luottamuksellisuutta sekä osoitusvelvollisuutta.

Hallintakysymys ei ole: “Voimmeko koskaan lokittaa henkilötietoja?” Parempi kysymys on: “Mitä henkilötietoja meidän on lokitettava tietoturvaa, tietoturvapoikkeamiin reagointia ja vaatimustenmukaisuutta varten, mikä oikeusperuste tukee sitä, mitä suojatoimia sovelletaan ja milloin tiedot on poistettava, anonymisoitava tai asetettava hyväksytyn säilytysvelvoitteen piiriin?”

Clarysecin yritystason tietosuojapolitiikkakirjasto käsittelee tätä jännitettä suoraan. Tietosuoja- ja yksityisyydensuojapolitiikka, politiikan toimeenpanovaatimukset, kohta 6.2.1 toteaa:

Vain tiettyyn ja oikeutettuun liiketoimintatarkoitukseen tarpeellisia tietoja saa kerätä ja käsitellä.

Pk-yrityksille sama periaate esitetään Tietosuoja- ja yksityisyydensuojapolitiikka-sme, politiikan toimeenpanovaatimukset, kohdassa 6.2.1:

Vain välttämättömät henkilötiedot saa kerätä ja säilyttää.

Tämän lauseen tulisi ohjata jokaista lokituksen suunnittelupäätöstä. Onko jokainen kenttä jokaisessa lokilähteessä tarpeellinen määritettyä tietoturvaan liittyvää, operatiivista, lakisääteistä tai sopimusperusteista tarkoitusta varten?

Miksi ISO 27701 muuttaa lokituskeskustelua

ISO/IEC 27001:2022 antaa hallintajärjestelmän rakenteen: soveltamisalan, sidosryhmät, riskien arvioinnin, riskien käsittelyn, operatiivisen ohjauksen, seurannan, sisäisen auditoinnin ja jatkuvan parantamisen. ISO/IEC 27002:2022 antaa käytännön kontrolliohjeistusta lokituksesta, seurannasta, henkilötietojen tietosuojasta, todentavan aineiston keräämisestä, tallenteiden suojaamisesta, poistamisesta, pääsynhallinnasta ja toimittajahallinnasta. ISO/IEC 27701 laajentaa hallintamallin henkilötietojen hallintajärjestelmäksi keskittymällä henkilötietojen rekisterinpitäjiin ja käsittelijöihin, tietosuojarooleihin, henkilötietojen käsittelytoimien selosteisiin, sisäänrakennettuun tietosuojaan, oikeuksien käsittelyyn ja henkilötietojen käsittelijän velvoitteisiin.

Tietoturvalokien osalta ISO 27701 on merkityksellinen, koska se pakottaa esittämään tietosuojakohtaisia kysymyksiä, jotka tietoturvatiimit joskus ohittavat:

• Käsitteleekö lokilähde henkilötietoja rekisterinpitäjänä, henkilötietojen käsittelijänä, yhteisrekisterinpitäjänä vai alikäsittelijänä?
• Sisältyvätkö lokitiedot selosteeseen käsittelytoimista?
• Tietääkö organisaatio, mitkä lokikentät sisältävät henkilötietoja?
• Onko lokeissa oleva henkilötieto kytketty säilytys- ja poistosääntöihin?
• Informoidaanko käsittelijäasiakkaita henkilötietoihin kohdistuvan pääsyn lokituksesta, kun sopimus sitä edellyttää?
• Otetaanko lokit huomioon, kun vastataan tarkastus-, poisto- tai käsittelyn rajoittamista koskeviin pyyntöihin?
• Arvioidaanko henkilötietopoikkeamat tietosuojan, kyberturvallisuuden ja finanssialan raportointikynnysten näkökulmasta?

Clarysecin Henkilötietojen tietoturva- ja pääsynhallintapolitiikka muuntaa tämän operatiivisiksi vaatimuksiksi. Kohdasta Lokitus ja seuranta, kohta 4.6.1:

[Molemmat] Järjestelmäomistajan / sovellusomistajan TULEE määrittää henkilötietojen lokituksen soveltamisala todennustapahtumille, käyttöoikeustapahtumille, etuoikeutetuille toimille, henkilötietojen vientitoiminnalle ja olennaisille konfiguraatiomuutoksille REG12:ssa ennen tuotantokäyttöä tai olennaista muutosta.

Kohta 4.6.2 sulkee tämän jälkeen silmukan lokituksen, pääsynhallinnan ja säilytyksen välillä:

[Molemmat] Tietoturvavastaavan TULEE varmistaa, että henkilötietoja sisältäviin lokeihin pääsy on rajoitettu ja että ne on kytketty hyväksyttyyn säilytys- tai poistosääntöön REG02:ssa tai REG12:ssa ennen lokien seurannan aloittamista.

Tämä tekee PIMS-hallinnasta käytännöllistä. REG12 määrittää, mikä henkilötietojen lokitus on sallittua ja vaadittua. REG02 tunnistaa, missä henkilötiedot sijaitsevat, mukaan lukien lokit. Säilytys- ja poistosäännöt eivät ole jälkikäteen lisättävää paperityötä. Niistä tulee tuotantolokituksen ennakkoedellytyksiä.

Tietoturvalokit ovat tallenteita, todentavaa aineistoa ja henkilötietojen käsittelytoimintaa

Kypsän organisaation ei tule käsitellä lokeja kertakäyttöisenä teknisenä sivutuotteena. Lokit ovat tallenteita. Poikkeaman aikana niistä voi tulla oikeudellista todistusaineistoa. Kun ne sisältävät henkilötietoja, ne ovat myös tietosuojan hallinnan piiriin kuuluvaa käsittelydataa.

Clarysecin Lokitus- ja valvontapolitiikka määrittää lokien normalisointia koskevat odotukset. Hallintavaatimuksista, kohta 5.1.4:

Lokiformaattia ja normalisointia koskevat vaatimukset (esim. aikaleima, käyttäjätunnus, tapahtumatyyppi, lähde-IP)

Juuri nämä kentät tekevät lokeista hyödyllisiä tietoturvapoikkeamiin reagoinnissa. Ne ovat myös kenttiä, jotka usein tekevät lokeista henkilötietoja. Sama yritystason politiikka nostaa esiin sen, mitä ei saa tapahtua. Hallintavaatimuksista, kohta 5.3.3:

Arkaluonteisten tietojen tallentaminen selväkielisenä (esim. salasanat, kryptografiset salaisuudet)

Tarkoitus ei ole, että lokien tulisi välttää kaikkia tunnisteita. Tarkoitus on, että tunnisteiden on oltava tarkoituksellisia, suojattuja ja perusteltuja. Salasanoja, salaisuuksia, kokonaisia tokeneita ja tarpeettomia hyötykuormia ei tule lokittaa. Käyttäjätunnukset, IP-osoitteet ja tapahtumien metatiedot voivat olla tarpeellisia, mutta ne edellyttävät kontrolleja.

Pk-yrityksille Clarysecin Lokitus- ja valvontapolitiikka-sme sijoittaa tietosuojakatselmoinnin roolirakenteeseen. Roolit ja vastuut, kohta 4.3.1, edellyttää, että organisaatio:

Varmistaa, että henkilökohtaisiin tai arkaluonteisiin tietoihin liittyviä lokitietoja käsitellään GDPR:n ja muun tietosuojalainsäädännön mukaisesti.

Pk-yritysversio antaa myös selkeän säilytyksen perustasovaatimuksen. Hallintavaatimuksista, kohta 5.2.1:

Lokeja on säilytettävä vähintään 12 kuukautta, ellei pidempää säilytysaikaa edellytetä laissa tai sopimuksessa tai ellei se ole perusteltua aktiivisen poikkeaman tai oikeudellisen riidan yhteydessä.

Se asettaa myös suojausodotuksen. Hallintavaatimuksista, kohta 5.3.1:

Lokit on säilytettävä kirjoitussuojatuissa sijainneissa, ja pääsy on rajoitettava vain valtuutetulle henkilöstölle.

Yritystason tietoturvapoikkeamiin reagointia varten Todisteiden keräämisen ja forensiikan politiikka, politiikan toimeenpanovaatimukset, kohta 6.3.1 edellyttää:

Palomuureista, SIEM-järjestelmästä, päätelaiteagenteista, identiteetin- ja pääsynhallinta-alustoista (IAM) ja pilvialustoista peräisin olevat lokit tulee viedä ja säilyttää muuttumattomissa formaateissa.

Pk-yritysversio lisää suhteellisuutta koskevan suojakaiteen. Todisteiden keräämisen ja forensiikan politiikka-sme, riskien käsittely ja poikkeukset, kohta 7.2.1 toteaa:

Minimoi keräämisen soveltamisala; kerää vain se, mikä on tarpeellista.

Tämä on tietosuojatietoisen lokituksen ydin: säilytä se, mikä on tarpeellista, osoita miksi se on tarpeellista, rajoita pääsyä siihen ja poista se, kun hyväksytty käyttötarkoitus päättyy.

Clarysecin kontrollimalli tietosuojaturvalliselle todentavalle aineistolle

Zenith Blueprint: auditoijan 30 vaiheen tiekartta sijoittaa lokituksen Kontrollit käytännössä -vaiheeseen, vaiheeseen 19: teknologiset kontrollit I. Opas selittää ISO/IEC 27002:2022:n kontrolliodotuksen:

A.8.15 – Lokitus: “Lokeja, joihin kirjataan toimintoja, poikkeuksia, vikoja ja muita olennaisia tapahtumia, tulee tuottaa, säilyttää, suojata ja analysoida.”

Sama vaihe ohjeistaa organisaatioita tuottamaan lokeja keskeisistä tapahtumista, säilyttämään ne turvallisesti niin, ettei niitä voida muuttaa, säilyttämään ne määritetyn ajan ja analysoimaan niitä SIEM-järjestelmän tai katselmointiprosessin kautta. Se kytkee lokituksen myös GDPR:n mukaiseen tietoturvaloukkauksesta ilmoittamiseen, DORA:n poikkeamatallenteisiin, NIS2-riskienhallintaan ja COBITin tietoturvalokien analysointiin.

Pelkkä lokitus ei kuitenkaan riitä. Samassa Kontrollit käytännössä -vaiheessa, vaiheessa 19, Zenith Blueprint käsittelee poistamista. Se varoittaa, että operatiivisen arvon ylittävä tietojen säilyttäminen lisää altistumista ja sääntelyriskiä, ja nostaa erikseen esiin varmuuskopiot, tilannevedokset ja arkistot. Tämä on olennaista, koska SIEM-järjestelmän säilytyssääntö on merkityksetön, jos replikoidut lokiarkistot tai pilvitallennussäiliöt säilyttävät samoja henkilötietoja määräämättömästi.

Vaiheessa 23: organisatoriset kontrollit, Zenith Blueprint käsittelee todentavan aineiston keräämistä. Sen mukaan poikkeamaa koskeva todentava aineisto on tunnistettava, kerättävä ja säilytettävä tavalla, joka on oikeudellisesti hyväksyttävä, luotettava ja tutkinnan tarpeiden mukainen. Se korostaa myös operatiivista todellisuutta: todentavaa aineistoa menetetään usein reagoinnin ensimmäisten minuuttien aikana, kun lokit kiertyvät yli, järjestelmiä käynnistetään uudelleen tai ylläpitäjät muuttavat vaarantuneita tilejä ennen tilannevedosten ottamista.

Vaihe 23 käsittelee myös henkilötietojen tietosuojaa ja suojaamista. Opas kuvaa henkilötiedot elinkaarikysymyksenä, joka edellyttää tietoisuutta tiedoista, luokittelua, pääsynhallintaa, maskausta, poistamista, salausta ja toimittajavelvoitteita. Lokien osalta tämä tarkoittaa, että SIEM, EDR, pilvipohjainen lokitusalusta ja tikettijärjestelmä on sisällytettävä henkilötietojen luetteloon.

Henkilötietojen lokitusta koskeva vaatimustenmukaisuuden vastaavuuskartoitus

Zenith Controls: vaatimustenmukaisuuden vastaavuusopas yhdistää ISO/IEC 27002:2022:n kontrollin 8.15, Lokitus, siihen liittyviin kontrolleihin, jotka ovat olennaisia henkilötietojen hallinnassa. Nämä suhteet osoittavat, miksi lokitus ei ole vain SOC:n huolenaihe.

Zenith Controls yhdistää Lokituksen myös ISO/IEC 27002:2022:n kohtaan 8.15, ISO/IEC 27035-1:een ja ISO/IEC 27035-2:een poikkeamien hallinnan osalta, ISO/IEC 27701:een henkilötietojen käsittelytoimien lokituksen osalta, ISO/IEC 27017:ään pilviauditointilokien osalta, ISO/IEC 27018:aan pilvipalveluiden henkilötietopääsyn lokituksen osalta, ISO/IEC 27005:een riittämättömän lokituksen riskeistä, ISO/IEC 27033:een verkkotoiminnan lokituksen osalta ja ISO/IEC 15408-2:een arvioitujen tuotteiden auditointitoiminnallisuuden osalta.

Tietosuojan osalta Zenith Controls yhdistää ISO/IEC 27002:2022:n kontrollin 5.34, Henkilötietojen tietosuoja ja suojaaminen, omaisuusluetteloon, tietojen maskaukseen, pilvipalveluihin, luokitteluun, tietojen siirtoon, pääsynhallintaan, identiteetinhallintaan sekä projektien ja muutosten tietoturvakatselmointiin. Lokien hallintaohjelmassa nämä yhteydet muuttuvat käytännön suunnitteluvaatimuksiksi:

• Luetteloi lokivarastot henkilötietojen sijainteina.
• Maskaa tai tokenisoi henkilötietoja, kun täysiä tunnisteita ei tarvita.
• Katselmoi pilvilokituspalvelut ja SIEM-toimittajat pilvi- ja toimittajakontrollien mukaisesti.
• Luokittele henkilötietoja sisältävät lokit arkaluonteisiksi tallenteiksi.
• Hallinnoi lokivientejä ja -siirtoja henkilötietojen siirtoina.
• Rajoita lokipääsy identiteetin- ja etuoikeutetun pääsyn hallinnan kontrollien avulla.
• Katselmoi sovelluslokitukseen tehtävät muutokset ennen tuotantojulkaisua.

GDPR, NIS2 ja DORA: yksi loki, kolme sääntelynäkökulmaa

Samaa lokimerkintää voidaan tarkastella eri tavoin GDPR:n, NIS2:n ja DORA:n nojalla.

GDPR:n nojalla organisaatio kysyy, sisältääkö lokimerkintä henkilötietoja, mikä oikeusperuste tukee käsittelyä, ovatko tiedot tarpeellisia, kuinka kauan niitä säilytetään, kuka voi käyttää niitä, luovutetaanko niitä henkilötietojen käsittelijöille tai asiakkaille ja onko ne huomioitava oikeuksia koskevassa pyynnössä tai tietoturvaloukkauksen arvioinnissa.

NIS2:n nojalla organisaatio kysyy, tukevatko lokit kyberturvallisuusriskien hallintaa, poikkeamien käsittelyä, liiketoiminnan jatkuvuutta, pääsynhallintaa, toimitusketjun turvallisuutta ja kontrollien tehokkuuden arviointia. NIS2 Article 20 asettaa hallintoelimille vastuun kyberturvallisuuden riskienhallintatoimenpiteiden hyväksymisestä ja valvonnasta. Article 21 edellyttää asianmukaisia ja oikeasuhtaisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä, mukaan lukien poikkeamien käsittely, liiketoiminnan jatkuvuus, toimitusketjun turvallisuus, turvallinen kehittäminen, haavoittuvuuksien käsittely, vaikuttavuuden arviointi, kyberhygienia, pääsynhallinta ja omaisuudenhallinta. Article 23 luo merkittävien poikkeamien vaiheistetun raportoinnin, mukaan lukien ennakkovaroitus 24 tunnin kuluessa, ilmoitus 72 tunnin kuluessa ja loppuraportti yhden kuukauden kuluessa.

DORA:n nojalla finanssialan toimijoiden on käytettävä dokumentoitua ICT-riskien hallinnan viitekehystä. DORA Article 5 osoittaa vastuun hallintoelimelle. Article 10 käsittelee havaitsemista. Article 17 edellyttää TVT-poikkeamien hallintaprosessia. Article 18 käsittelee TVT-poikkeamien ja kyberuhkien luokittelua. Article 19 käsittelee merkittävien TVT-poikkeamien raportointia. Lokit tukevat havaitsemista, luokittelua, juurisyyanalyysiä, vaikutusten arviointia, reagointia, palautumista ja korjaavien toimenpiteiden todentavaa aineistoa.

Yksityiskohtaisempi kontrollien vastaavuustaulukko auttaa tietoturvajohtajaa perustelemaan lokitusta ilman epämääräisiä väitteitä, kuten “tarvitsemme sitä tietoturvaa varten”.

Rakenna henkilötietojen lokituksen soveltamisala REG12:ssa

Clarysecin asiakas käsittelisi klo 02.17 alkavan SIEM-poikkeaman ennen kuin se koskaan tapahtuu. Organisaatio aloittaa asiakasrajapinnan sovelluksesta, joka käsittelee käyttäjätilitietoja. Ennen tuotantokäyttöä sovellusomistaja määrittää REG12:n avulla henkilötietojen lokituksen soveltamisalan. Tavoitteena on kerätä riittävästi tapahtumia tietoturvaa ja sääntelyn mukaista todentavaa aineistoa varten ilman tarpeettomien henkilötietojen tai hyötykuormasisällön lokittamista.

Seuraavaksi tietosuojavastaava vahvistaa, toimiiko organisaatio kunkin lokilähteen osalta rekisterinpitäjänä, henkilötietojen käsittelijänä vai molempina. Jos organisaatio on henkilötietojen käsittelijä, asiakkaan sopimusohjeet ja alikäsittelijöitä koskevat luovutukset voivat rajoittaa lokipääsyä ja jakamista. Jos se on rekisterinpitäjä, tietosuojaselosteet, oikeusperuste ja oikeuksien käsittely on huomioitava.

Tiedon omistaja päivittää tämän jälkeen REG02:n sisältämään aktiiviset lokivarastot, SIEM-indeksit, arkistot, varmuuskopiot ja väliaikaiset forensiset viennit. Tämä on linjassa Henkilötietojen säilytys-, poisto- ja hävityspolitiikan kanssa, Varmuuskopiot, arkistot, replikat, lokit ja väliaikaiset tiedostot, kohta 4.4.1:

[Molemmat] Järjestelmäomistajan / sovellusomistajan TULEE tunnistaa REG02:ssa aktiiviset tietovarastot, arkistot, varmuuskopiot, replikat, lokit, staging-alueet ja väliaikaiset tiedostot, jotka sisältävät henkilötietoja, ennen tuotantokäyttöönottoa ja jokaisen vuosittaisen säilytyskatselmoinnin aikana.

Tietojen säilytys- ja hävityspolitiikan tulee tämän jälkeen sovittaa liiketoiminnan säilytyssäännöt lakisääteisiin, sopimusperusteisiin ja todentavan aineiston säilyttämistä koskeviin vaatimuksiin.

Lopuksi tietoturvatiimi konfiguroi SIEM-järjestelmän niin, että salasanat, salaisuudet ja hyötykuormien rungot pudotetaan tai redaktoidaan ennen lokien keräämistä. Henkilötietoja sisältävät lokit kohdistetaan rajoitettuihin indekseihin. Säilytys toteutetaan automaattisesti, ellei poikkeamaa tai oikeudellista säilytysvelvoitetta hyväksytä. Poistotoimet kirjataan lokiin. Forensiset viennit edellyttävät hyväksyntää ja hallussapitoketjun seurantaa. Mittaristot näyttävät pseudonymisoituja tunnisteita, kun täyttä henkilöllisyyttä ei tarvita. Historiallisten lokien noutoa testataan sisäisissä auditoinneissa.

Tässä on ero väitteen “lokitamme tietoturvaa varten” ja osoituksen “lokitamme vain sen, mikä on tarpeellista, suojaamme sen, säilytämme sen hyväksyttyjen sääntöjen mukaisesti ja voimme käyttää sitä todentavana aineistona rikkomatta tietosuojavelvoitteita” välillä.

DSAR, poistaminen ja lokit: päätä ennen pyynnön saapumista

Yksi vaikeimmista kysymyksistä on, onko lokit haettava, luovutettava tai poistettava vastauksena rekisteröidyn tarkastuspyyntöön tai poistopyyntöön. Vastaus riippuu roolista, käyttötarkoituksesta, oikeusperusteesta, toteutettavuudesta, poikkeuksista ja säilytysvelvoitteista. Hallintaprosessia ei kuitenkaan voida keksiä uudelleen pyyntö kerrallaan.

Rekisteröidyn oikeuksien hallintapolitiikka, Identiteetin varmennus, soveltamisala ja arviointi, kohta 4.2.3 toteaa:

[Rekisterinpitäjä] Prosessin omistajan / liiketoimintavastaavan TULEE tunnistaa REG02:sta olennaiset järjestelmät, tallenteet, käyttötarkoitukset, henkilötietoryhmät, vastaanottajat ja säilytysrajoitteet ennen toteuttamisen arviointia.

Tämä tarkoittaa, että lokien on oltava REG02:ssa selkein metatiedoin: mitä henkilötietoryhmiä ne sisältävät, mitä tarkoitusta ne palvelevat, mitä säilytysrajoitetta sovelletaan ja voidaanko pyyntö toteuttaa suoralla luovutuksella, tiivistetyllä pääsyllä, rajoittamisella, poistamisella säilytysajan päättyessä tai kieltäytymisellä dokumentoidun oikeudellisen perusteen nojalla.

Clarysec suosittelee kolmitasoista lähestymistapaa:

1. Operatiiviset lokit, joiden tietosuojavaikutus on vähäinen, kuten pseudonyymejä käyttäjätunnuksia käyttävät järjestelmätapahtumalokit, voivat olla haettavissa ja luovutettavissa soveltuvin osin.
2. Tietoturvalokit, joiden tietoturvaan liittyvä arkaluonteisuus on suuri, kuten SIEM-korrelaatiotiedot tai uhkatiedustelukonteksti, voivat edellyttää suodatusta, tiivistettyä luovutusta tai rajoittamista, jotta havaitsemislogiikkaa tai kolmannen osapuolen tietoja ei paljasteta.
3. Aktiivisen poikkeaman tai oikeudellisen säilytysvelvoitteen alainen forensinen todistusaineisto ei saa muuttua kevyin perustein. Poistamista voidaan lykätä tai rajoittaa, jos se on oikeudellisesti perusteltua, ja päätös tulee dokumentoida tietosuoja- ja lakiasioiden sidosryhmien toimesta.

Jos tietosuojavastaava ja SOC keskustelevat jokaisesta DSAR-pyynnöstä alusta alkaen, organisaation toiminta on epäyhtenäistä ja hidasta. Jos REG02 ja REG12 ovat ajan tasalla, oikeuksien käsittely perustuu todentavaan aineistoon.

Tietoturvaloukkaukset ja poikkeamien raportointi: yksi tapahtuma, useita kelloja

Klo 02.17 annettu hälytys voi käynnistää useita kelloja. GDPR:n mukainen henkilötietojen tietoturvaloukkauksen arviointi voi edellyttää ilmoitusta valvontaviranomaiselle, jos riskikynnykset täyttyvät. NIS2:n mukainen merkittävän poikkeaman raportointi voi edellyttää ennakkovaroitusta 24 tunnin kuluessa, ilmoitusta 72 tunnin kuluessa ja loppuraporttia. DORA voi edellyttää merkittävän TVT-poikkeaman raportointia alku-, väli- ja loppuvaiheissa. Asiakassopimuksissa voi olla vielä lyhyempiä ilmoitusikkunoita.

Clarysecin Henkilötietopoikkeamien ja tietoturvaloukkausten hallintapolitiikka käsittelee tätä useiden ilmoituskynnysten ongelmaa suoraan. Luokittelu ja tietoturvaloukkauksen arviointi, kohta 4.2.6:

[Ehdollinen] Tietosuojavastaavan / PIMS-päällikön TULEE arvioida soveltuvat lakisääteiset, alakohtaiset, finanssialan, kyberturvallisuuteen liittyvät, sopimusperusteiset, asiakas- ja palvelunsaajaraportoinnin käynnistävät tekijät jokaisen vaikutuksiltaan merkittävän henkilötietopoikkeaman osalta ja kirjata soveltuvuuden tulos REG01:een, REG08:aan ja REG10:een.

Luokittelun aikana organisaation tulee kysyä:

• Pääsikö hyökkääjä henkilötietoihin vai vain metatietoihin?
• Altistivatko lokit lisää henkilötietoja luvattomille käyttäjille?
• Tarvitaanko lokeja vaikutuksen kohteena olevien henkilöiden, järjestelmien ja aikavälin määrittämiseen?
• Säilytetäänkö lokit muuttumattomina ja onko niihin pääsy rajoitettu?
• Onko poikkeamaan liittyvä säilytysvelvoite keskeyttänyt relevanttien lokien poistamisen?
• Vaikuttaako tapahtuma käsittelijäasiakkaisiin, finanssialan asiakkaisiin tai palvelunsaajiin?
• Mitkä raportointikellot soveltuvat ja kuka vastaa kustakin ilmoituksesta?

Hyvin hallitut lokit nopeuttavat raportointia, koska ne antavat päätöksentekijöille luotettavat faktat. Puutteellinen lokitus aiheuttaa viivettä. Ylilokitus luo tietosuojariskin. Oikea ratkaisu on kohdennettu, suojattu ja kartoitettu lokitus.

Toimittaja- ja pilvilokitus: SIEM-järjestelmään piiloutuva käsittelijäongelma

Useimmat organisaatiot eivät säilytä kaikkia lokeja täysin omassa hallinnassaan olevassa infrastruktuurissa. Lokit virtaavat SIEM-alustoihin, EDR-portaaleihin, pilvinatiiveihin lokituspalveluihin, havainnointityökaluihin, tikettijärjestelmiin sekä hallinnoituihin havaitsemis- ja reagointipalveluihin. GDPR:n nojalla nämä palveluntarjoajat voivat olla henkilötietojen käsittelijöitä tai alikäsittelijöitä. NIS2:n ja DORA:n nojalla ne voivat olla myös suoria toimittajia, kolmannen osapuolen TVT-palveluntarjoajia, hallinnoituja palveluntarjoajia tai hallinnoidun tietoturvapalvelun tarjoajia.

NIS2 Article 21 sisältää nimenomaisesti toimitusketjun turvallisuuden, toimittajien haavoittuvuudet ja toimittajien yleiset kyberturvallisuuskäytännöt. DORA lisää finanssialan toimijoille yksityiskohtaiset kolmannen osapuolen TVT-riskien vaatimukset, mukaan lukien sopimusta edeltävä huolellisuus, tietorekisterit, auditointi- ja pääsyoikeudet, poikkeama-avustus, tietojen sijainti, tietosuojalausekkeet, irtautumisstrategiat ja kriittisiä tai tärkeitä toimintoja koskevat sopimusmääräykset.

Henkilötietoja sisältävien tietoturvalokien osalta toimittajakatselmointien tulee sisältää seuraavat kysymykset:

SIEM-sopimus ei ole vain ohjelmistotilaus. Se on henkilötietojen käsittelyä ja poikkeaman todentavaa aineistoa koskeva riippuvuus.

Auditointinäkökulma: miten arvioijat testaavat henkilötietoja tietoturvalokeissa

Hyvä auditoija ei hyväksy pelkkää väitettä siitä, että “lokit on suojattu”. Hän testaa ketjun politiikasta konfiguraatioon, todentavaan aineistoon ja katselmointiin.

Käytännön auditointitesti on yksinkertainen mutta paljastava: pyydä SOC:ia noutamaan kymmenen kuukauden takainen lokimerkintä, joka osoittaa etuoikeutetun pääsyn muutoksen pilvialustalla, todistamaan kuka käytti kyseistä lokia, osoittamaan ettei sitä ole muutettu, näyttämään säilytyssääntö, joka salli sen olemassaolon, näyttämään sen sisältämät henkilötietokentät ja osoittamaan, miten sitä käsiteltäisiin DSAR-pyynnössä tai poikkeamaraportissa. Jos tiimi ei pysty vastaamaan tietoturvan, tietosuojan ja vaatimustenmukaisuuden näkökulmista, hallinta on puutteellista.

Yleiset havainnot henkilötietoja sisältävien lokien auditoinneissa

Clarysec näkee usein samoja malleja:

• Sovellustiimit lokittavat virheenkorjausta varten täydet pyyntöjen hyötykuormat, mukaan lukien nimet, sähköpostiosoitteet, tilinumerot tai viestisisällön.
• SIEM-indeksit ovat avoinna laajoille IT-järjestelmänvalvojaryhmille rajoitettujen SOC-roolien sijasta.
• Lokien säilytys asetetaan globaalisti huomioimatta henkilötietojen arkaluonteisuutta, asiakassopimuksia tai poikkeamaan liittyvän säilytysvelvoitteen sääntöjä.
• Pilvipalveluntarjoajan lokit ovat käytössä, mutta palveluntarjoajan ylläpitäjien pääsyä asiakkaan lokitietoihin ei katselmoida.
• DSAR-menettelyissä ei mainita lokeja, SIEM-tapauksia tai forensisia vientitiedostoja.
• Tietoturvapoikkeamiin reagoinnin pelikirjat säilyttävät todentavan aineiston, mutta tietosuojatiimejä ei oteta mukaan luokitteluun.
• Varmuuskopiot ja arkistot säilyttävät lokien henkilötietoja pidempään kuin SIEM.
• Kehittäjät voivat muuttaa tuotannon lokitustasoja ilman tietosuoja- tai tietoturvakatselmointia.
• Testiympäristöt vastaanottavat henkilötietoja sisältäviä tuotantolokeja.
• Organisaatiolla on NIS2- tai DORA-raportointivelvoitteita, mutta se ei pysty noutamaan luotettavaa todentavaa aineistoa nopeasti.

Nämä havainnot johtuvat harvoin pahasta tarkoituksesta. Ne johtuvat siiloutuneesta omistajuudesta. Tietoturvalokit sijoittuvat SOC:n, alustasuunnittelun, tietosuojan, lakiasioiden, vaatimustenmukaisuuden, auditoinnin ja toimittajien väliin. Jos kukaan ei omista koko elinkaarta, aukkoja syntyy.

Clarysecin tarkistuslista auditointivalmista lokien hallintaa varten

Käytä tätä tarkistuslistaa työskentelyn lähtökohtana seuraavassa hallintakatselmoinnissa:

1. Määritä, mitkä lokilähteet voivat sisältää henkilötietoja: IAM, sovellus, API-yhdyskäytävä, SIEM, EDR, pilvi, tietokanta, verkko, fyysinen pääsy ja tikettijärjestelmä.
2. Kirjaa jokainen lokivarasto REG02:een, mukaan lukien aktiiviset varastot, arkistot, varmuuskopiot, replikat ja väliaikaiset forensiset viennit.
3. Määritä henkilötietojen lokituksen soveltamisala REG12:ssa ennen tuotantokäyttöä tai olennaisia muutoksia.
4. Tunnista tietoturvalokien käsittelyn tarkoitus ja oikeusperuste.
5. Kiellä salasanojen, salaisuuksien, kokonaisten tokenien ja tarpeettomien hyötykuormien tallentaminen lokeihin.
6. Käytä maskausta, tiivistealgoritmeja tai pseudonymisointia, kun täysiä tunnisteita ei tarvita.
7. Rajoita henkilötietoja sisältäviin lokeihin pääsyä roolin perusteella ja sisällytä etuoikeutetun pääsyn katselmointi.
8. Säilytä korkean arvon lokit muuttumattomissa tai kirjoitussuojatuissa formaateissa.
9. Määritä säilytys lokityypin, lakisääteisen velvoitteen, sopimuksen, poikkeamatarpeen ja tietosuojariskin perusteella.
10. Toteuta poikkeamaan liittyvät säilytysvelvoitteet hyväksynnän, soveltamisalan ja päättymisajan kanssa.
11. Sisällytä lokit DSAR- ja poistopyyntöjen arviointilogiikkaan.
12. Katselmoi SIEM-, EDR-, pilvi- ja MDR-toimittajat henkilötietojen käsittelijöinä tai TVT-kolmansina osapuolina.
13. Testaa historiallisten lokien nouto ja todentavan aineiston eheys.
14. Kartoita lokitus GDPR:n, ISO 27701:n, NIS2:n, DORA:n, NIST CSF:n ja COBITin raportointitarpeisiin.
15. Kouluta SOC-, tietosuoja- ja sovellustiimit siitä, mitä saa ja mitä ei saa lokittaa.

Tämä tarkistuslista muuttaa tietosuojatietoisen lokituksen toistettavaksi kontrolliprosessiksi.

Dilemmasta hallitustason luottamukseen

NIS2 tekee kyberturvallisuudesta johdon vastuun. DORA tekee hallintoelimestä vastuullisen ICT-riskien hallinnasta, digitaalisen operatiivisen häiriönsietokyvyn strategiasta, tietojen luottamuksellisuudesta, poikkeamaviestinnästä ja kolmannen osapuolen TVT-palveluja koskevista politiikoista. ISO/IEC 27001:2022 edellyttää, että ylin johto sovittaa tietoturvallisuuden hallintajärjestelmän liiketoimintatavoitteisiin, osoittaa vastuut, tarjoaa resurssit ja edistää jatkuvaa parantamista.

Henkilötiedot tietoturvalokeissa eivät siksi ole kapea tekninen yksityiskohta. Ne ovat hallitustason luottamuskysymys. Organisaation kyky havaita poikkeamia, suojata henkilötietoja, säilyttää todentavaa aineistoa, vastata asiakkaille, täyttää viranomaisvaatimukset ja palauttaa toiminta riippuu lokituspäätöksistä, jotka tehdään kauan ennen poikkeamaa.

Parhaat hallintaohjelmat eivät valitse tietosuojan ja tietoturvan välillä. Ne määrittävät vankan tietoturvan edellyttämän vähimmäislokituksen, suojaavat kyseisen lokituksen tarvittaessa arkaluonteisina henkilötietoina ja kytkevät sen säilytykseen, todentavaan aineistoon, oikeuksien käsittelyyn ja toimittajavelvoitteisiin.

Seuraavat askeleet Clarysecin kanssa

Jos SIEM-, IAM-, EDR- tai pilvilokisi sisältävät henkilötietoja, nyt on aika hallita niitä tarkoituksellisesti.

Clarysec voi auttaa sinua:

• Rakentamaan henkilötietojen lokituksen soveltamisalan REG12:n avulla ja sovittamaan sen yhteen Henkilötietojen tietoturva- ja pääsynhallintapolitiikan kanssa.
• Luetteloimaan lokivarastot, arkistot, varmuuskopiot ja forensiset viennit REG02:n ja Henkilötietojen säilytys-, poisto- ja hävityspolitiikan avulla.
• Sovittamaan lokituksen, seurannan, todentavan aineiston ja tietosuojakontrollit yhteen Zenith Blueprint -oppaan kanssa.
• Kartoittamaan kontrollit GDPR:n, ISO 27701:n, NIS2:n, DORA:n, NIST CSF:n ja COBITin välillä Zenith Controls -oppaan avulla.
• Valmistelemaan auditointivalmiin todentavan aineiston ISO-, tietosuoja-, NIST-, COBIT-, NIS2- ja DORA-varmennuskatselmointeihin.

Aloita yhdestä korkean riskin järjestelmästä: IAM-alustasta, SIEM-järjestelmästä tai asiakasrajapinnan sovelluksesta. Tunnista, mitä henkilötietoja lokeihin päätyy, miksi niitä tarvitaan, kuka voi käyttää niitä, kuinka kauan niitä säilytetään ja miten niitä käytettäisiin poikkeaman tai rekisteröidyn oikeuksia koskevan pyynnön aikana. Tämä yksittäinen harjoitus paljastaa, onko nykyinen lokitusohjelmasi vain operatiivinen vai aidosti auditointivalmis.