Tietoturvalokitus tuottaa tapahtumatietoa, jonka avulla organisaatio voi havaita väärinkäytön, selvittää häiriön ja arvioida sen vaikutuksia. Käyttökelpoinen loki kertoo esimerkiksi, mikä tunnus teki vientipyynnön, missä palvelussa pyyntö tehtiin, milloin se tapahtui ja onnistuiko toiminto. Se ei tarvitse kopiota viedyn asiakasrekisterin sisällöstä.
Lokituksen suunnittelussa ratkaistaan kolme eri kysymystä: mitä pitää havaita, mitä tietoa sen havaitseminen edellyttää ja kuka tekee havainnon jälkeen jotakin. Tässä oppaassa kuvitteellinen ohjelmistoyritys Saaristodata rakentaa asiakaspalvelunsa lokituksen näiden kysymysten ympärille. Sen esimerkkiajat ja hälytysrajat ovat omia perusteltavia suunnitteluvalintoja. Niitä ei pidä kopioida yleisinä lakivaatimuksina.
Aloita tapahtumasta, jonka haluat selvittää
Saaristodatan asiakaspalvelu käsittelee tilaajien yhteystietoja ja palvelupyyntöjä. Yritys tunnistaa kolme ensisijaista riskiä: käyttäjätilin kaappaus, tarpeeton laaja tietojen vienti ja ylläpito-oikeuden luvaton lisääminen. Näiden tapahtumien selvittämiseen tarvitaan eri tietoja. Pelkkä verkkopalvelimen pyyntöloki ei välttämättä kerro, annettiinko käyttäjälle uusi rooli tai valmistuiko tietojen vienti.
Lokilähteet yhdistetään järjestelmien ja riippuvuuksien kartoitukseen. Tunnistautumispalvelu kertoo kirjautumisesta, sovellus käyttöoikeuksista ja vientitoiminto käsittelyn tuloksesta. Jokaiselle lähteelle nimetään omistaja, joka tietää, miten lokitus otetaan käyttöön ja miten sen katkeaminen huomataan. Myös ulkoistetun palvelun tiedonsaanti selvitetään ennen häiriötä.
Lokien kerääminen ei itsessään oikeuta käsittelemään mitä tahansa henkilötietoja. Tietosuoja-asetuksen tarkoitussidonnaisuus, minimointi ja säilytyksen rajoittaminen koskevat myös turvallisuuden vuoksi kerättyä aineistoa. Organisaatio määrittää käsittelyperusteen ja antaa tarvittavat tiedot ihmisille. Tietoturvapolitiikka määrää vastuut, mutta varsinaisessa lokisuunnitelmassa kuvataan toteutettava keruu.
Täytetty lokisuunnitelma asiakaspalvelulle
Saaristodata hyväksyy seuraavan ensimmäisen version. Tapahtumien nimet ovat tässä esimerkin omia tunnisteita, eivät tietyn tuotteen valmiita tapahtumatunnuksia.
| Lähde ja tapahtuma | Kerättävä tieto | Käyttötarkoitus ja ensimmäinen toimi |
|---|---|---|
| Tunnistautuminen: epäonnistunut yritys | Aika, palvelu, tunnuksen sisäinen viite, lähdeosoite ja virheluokka | Toistuvan yrityssarjan tutkiminen; verrataan saman tunnuksen onnistumisiin |
| Sovellus: vienti valmistui | Tekijän viite, rooli, aineistoryhmä, rivimäärä ja pyynnön viite | Poikkeavan viennin arviointi; tarkistetaan hyväksytty työtehtävä |
| Hallinta: rooli muuttui | Muutoksen tekijä, kohdetunnus, vanha ja uusi rooli, hyväksynnän viite | Luvattoman oikeuden tunnistaminen; hyväksyntä tarkistetaan erillisestä järjestelmästä |
| Keräin: lähde hiljeni | Lähteen nimi, viimeinen vastaanotto ja yhteystarkistuksen tulos | Keruuvajeen havaitseminen; selvitetään yhteys ja lähteen asetukset |
Tapahtumaan lisätään lähdejärjestelmän tuottama yksilöivä viite, jotta sama merkintä voidaan löytää uudelleen. Lähteen tapahtuma-aika ja keskitetyn keräimen vastaanottoaika pidetään erillään. Jos verkko katkeaa puoleksi tunniksi, vastaanottoajan käyttäminen tapahtuma-aikana muuttaisi tutkinnan aikajärjestystä.
Roolimuutos on jäljitettävä myös silloin, kun sen tekee taustapalvelu. Yhteisen ylläpitotunnuksen sijaan tarvitaan selvitettävä yhteys tekijään tai hyväksyttyyn automaatioon. Tämä ei tarkoita, että henkilön nimi pitäisi kopioida jokaiseen tapahtumaan. Sisäinen tunniste voi riittää, jos sen yhteys käyttäjätiliin ja tarvittava historia ovat hallitusti saatavilla.
Rajaa pois sisältö, joka ei auta tarkoitusta
Vientitapahtuman lokiin ei tallenneta asiakaslistaa, palvelupyynnön vapaata tekstiä tai käyttäjän syöttämää salasanaa. Maksutiedon sijaan käytetään tapahtumaviitettä. Istunnon tunnistamiseen valitaan erillinen tekninen viite, jolla ei voi kirjautua palveluun. Todellista istuntoavainta ei pidä tehdä tutkijan saataville lokitiedoston kautta.
Virhetilanteiden käsittely tarvitsee erityistä huomiota. Kehittäjän ottama laaja virheenjäljitys voi tallentaa koko HTTP-pyynnön mukana yhteystietoja tai käyttöavaimia. Saaristodata tarkistaa ennen julkaisua, että virheloki sisältää virheluokan, käsittelyvaiheen ja pyynnön viitteen. Tarvittava ongelma voidaan toistaa erillisellä synteettisellä aineistolla, jolloin tuotantoasiakkaan viestiä ei tarvitse kopioida kehitysympäristöön.
Myös käyttäjätunnuksen kenttä voi sisältää vahingossa salasanan. Järjestelmän suunnittelussa mietitään, tarvitaanko epäonnistuneen tunnuksen vapaata syötettä lainkaan vai voidaanko lokittaa vain tunnistetun tilin viite ja muu tapahtumatieto. Jos salaisuus päätyy lokiin, sen korjaaminen edellyttää altistuksen arviointia sekä tarvittaessa salaisuuden vaihtamista ja lokikopioiden hallittua käsittelyä. Tietojen minimoinnin käytännöt auttavat tarkastelemaan myös näitä huomaamattomia tietovirtoja.
Rakenna aikajana ennen johtopäätöstä
Kuvitteellisessa harjoituksessa tunnuksella asiakas-17 havaitaan kahdeksan epäonnistunutta kirjautumista ja yksi onnistuminen. Kaksi minuuttia myöhemmin samaan tiliin liittyvä vienti valmistuu. Tilanne näyttää epäilyttävältä, mutta tieto ei vielä todista tietomurtoa tai työntekijän väärinkäytöstä.
Tutkija kirjaa havainnot erikseen tulkinnoista: kirjautumistapahtuma kello 08.41 UTC, vienti kello 08.43 UTC, aineiston määrä 2 400 riviä, lähdeosoite eri kuin tilin viimeaikaisessa käytössä. Hän tarkistaa, kuuluiko vienti hyväksyttyyn asiakassiirtoon ja oliko käytössä yrityksen vaihtunut verkkoyhteys. IP-osoitteen maantieteellinen paikannus ei yksin ratkaise käyttäjän sijaintia tai henkilöllisyyttä. IP-osoitteen henkilötietoluonne ja sen tunnistamisen rajat on syytä ymmärtää myös hälytysten tulkinnassa.
Harjoituksen lopputulos on tässä tapauksessa luvaton istunto: käyttäjä kiistää toiminnan, vientitehtävää ei ollut hyväksytty ja istunnon muita tapahtumia löytyy samalta jaksolta. Vastetoiminnasta vastaava henkilö sulkee istunnon sovitun menettelyn mukaisesti ja arvioi lisätoimet. Lokitutkija ei muuta havaintoa suoraan varmaksi väitteeksi kaikkien rivien ulkopuolisesta vastaanottamisesta, jos loki osoittaa vain viennin valmistumisen. Epävarmuus kirjataan vaikutusten arviointiin.
Suojaa lokit erikseen tuotantopalvelusta
Jos sama vaarantunut ylläpitotunnus voi muuttaa sekä asiakastietoja että niiden käyttöjälkiä, selvittäminen vaikeutuu. Saaristodata lähettää keskeiset tapahtumat erilliseen lokiympäristöön. Sovellus saa lähettää omia tapahtumiaan, mutta sen palvelutunnuksella ei voi poistaa keskitettyä aineistoa. Tutkija saa hakea tietoja tehtävänsä laajuudessa, ja lokiympäristön hallintaoikeudet rajataan erikseen.
Tämä erottelu ei poista kaikkia riskejä. Vaarantunut lähde voi jättää tapahtuman muodostamatta tai lähettää väärää tietoa. Siksi tapahtumia verrataan tarvittaessa riippumattomiin lähteisiin ja keruun toimivuutta seurataan. Muuttumaton tallennus voi auttaa havaitsemaan myöhempää muuttamista, mutta se ei tee alun perin virheellisestä tapahtumasta totta eikä takaa yksin näytön oikeudellista painoarvoa.
Siirtoyhteydet, tallennus, avaimet ja varmuuskopiot arvioidaan kokonaisuutena. Henkilötietojen salaus ja avainten hallinta koskevat myös lokeja. Lokien katselusta ja viennistä jää oma jälki. Jos tutkija tekee rajatun aineiston viennin, sille nimetään säilytyspaikka, käyttötarkoitus ja pääsyn saavat henkilöt.
Miten säilytysaika päätetään Suomessa?
Kyberturvallisuuskeskuksen lokitusohje kuvaa suojattavan kohteen mukaan yleensä kuuden ja 24 kuukauden välillä vaihtelevia säilytysaikoja. Samassa ohjeessa korostetaan tarpeellisuuden arviointia ja perustelemista. Tätä vaihteluväliä ei pidä tulkita kaikkien lokien lakisääteiseksi vähimmäisajaksi tai luvaksi säilyttää kaikkea kaksi vuotta. Erityissääntelyn piirissä oleva loki arvioidaan sitä koskevan säännöksen perusteella.
Saaristodata valitsee esimerkissään tilin ja oikeuksien turvallisuustapahtumille kuuden kuukauden ajan, koska asiakaspalvelun käyttöpoikkeamia havaitaan myös jälkikäteen asiakasreklamaatioiden yhteydessä. Se perustelee erikseen, miksi valitut tietokentät tarvitaan koko ajaksi. Lyhytikäistä teknistä virheenjäljitystä ei liitetä automaattisesti samaan säilytysaikaan: yritys valitsee sille seitsemän päivää ja poistaa sisällön, kun vian selvittäminen ei enää edellytä sitä. Nämä ovat kuvitteellisen ympäristön ratkaisuja, eivät yleinen suositustaulukko.
Tunnistetun loukkauksen rajattu tapahtumaote voidaan tarvita pidempään asian käsittelyä varten. Päätös koskee silloin nimettyä tapausta ja aineistoa, ei kaikkien lokien säilyttämistä varmuuden vuoksi. Omistaja määrittää uudelleenarvioinnin ja poistamisen. Säilytyksen rajoittamisen periaate auttaa erottamaan jatkuvan keruun ja yksittäisen tutkinnan tarpeet.
Poistumisen tarkastuksessa yritys hakee odotettua vanhempia tapahtumia sekä käyttöliittymästä että arkistosta. Samalla tarkistetaan tutkijoiden viennit ja palautuksen yhteydessä takaisin tulevat kopiot. Automaattisen poistotyön olemassaolo ei riitä, jos virhetilanteet jäävät käsittelemättä tai toinen indeksi säilyttää samat henkilötiedot.
Työntekijöiden lokit vaativat oman rajauksen
Työntekijän tunnukseen liittyviä lokitietoja ei muuteta huomaamatta työn tuottavuuden mittariksi. Suomessa työelämän tietosuojalain 21 § edellyttää siinä tarkoitettujen teknisen valvonnan ja tietoverkon käyttöä koskevien asioiden käsittelyä soveltuvassa vuoropuhelu- tai yhteistoimintamenettelyssä. Sen ulkopuolisissa yrityksissä ja yhteisöissä työntekijöille tai heidän edustajilleen on ennen päätöstä varattava tilaisuus tulla kuulluiksi. Työnantajan on tämän jälkeen määriteltävä valvonnan tarkoitus ja menetelmät sekä tiedotettava niistä.
Sähköisen viestinnän välitystietoihin voi lisäksi liittyä erityisiä käsittelyrajoja. Yleinen turvallisuustarkoitus tai henkilöstön allekirjoittama IT-ohje ei yksin anna oikeutta lukea viestejä. Henkilöstön IT-käyttösäännöt kuvaavat hyväksytyt menettelyt, ja työntekijän sähköpostin hakeminen ja avaaminen käsitellään omana oikeudellisena kysymyksenään.
Varmista, että hälytys johtaa toimintaan
Saaristodata määrittää vientihälytyksen vastaanottajaksi tietoturvan vastuuhenkilön ja hänen poissa ollessaan sovitun varahenkilön. Ensimmäinen tehtävä on tarkistaa tapahtuman oikeellisuus ja hyväksytty vientitarve. Vahvistettu epäily siirtyy tietoturvaloukkauksen käsittelyprosessiin. Kaikki tapahtumat eivät suoraan täytä ilmoituskynnystä, mutta selvittämistä ei lykätä työkalun täydellistä raporttia odotettaessa.
Käyttöönottoharjoituksessa luodaan luvallinen vienti synteettisellä aineistolla. Tapahtuma näkyy lähteessä ja keräimessä, mutta ilmoitus menee vanhalle postituslistalle. Havaittu puute korjataan, ja uusi harjoitus vahvistaa, että vastaanottaja kuittaa hälytyksen ja löytää tapahtuman. Tuloksesta kirjataan kellonajat, tapahtumaviite, havaittu puute ja korjaus.
Sama harjoitus ei vielä osoita, että kaikki hyökkäykset havaitaan. Yritys seuraa väärien hälytysten määrää, puuttuvia lähteitä ja havaintoja, jotka löytyivät muuta kautta. Hälytysrajaa muutettaessa säilytetään perustelu: toistuvien aiheettomien ilmoitusten poistaminen ei saa samalla peittää suunniteltua riskitapahtumaa. Salasanapolitiikan ja palautusmenettelyn muutokset huomioidaan kirjautumishälytyksissä.
SIEM-järjestelmä voi yhdistää tapahtumia ja tukea analyysiä, mutta hyöty riippuu lähteistä, säännöistä ja ihmisistä. Saaristodata hyväksyy ensimmäisen vaiheen vasta, kun jokainen valittu tapahtumaketju voidaan osoittaa keruusta päätökseen. Seuraavat lähteet lisätään tunnistetun tarpeen perusteella. Näin lokimäärän kasvu ei korvaa kykyä selvittää, mitä todella tapahtui.
Lähteet
- Kyberturvallisuuskeskus: näin keräät ja käytät lokitietoja: lokikentät, tarpeellisuus ja säilytysajan arviointi.
- Kyberturvallisuuskeskus: poikkeamien hallinnointi turvallisuuden parantajana: havaintokyvyn, lokien eriyttämisen ja vastetoiminnan järjestäminen.
- Yleinen tietosuoja-asetus: henkilötietojen käsittelyn periaatteet ja turvallisuus.
- Laki yksityisyyden suojasta työelämässä, erityisesti 21 §: tekniseen valvontaan liittyvät menettelyt ja tiedottaminen.