Tietoturvapoikkeaman vaikein osuus on yleensä sen jälkeen, kun itse poikkeama on ohi: kun yrityksen on selitettävä, mitä tapahtui, milloin se havaittiin, mitä tietoja oli mukana, keitä asia koski ja miksi tietyt päätökset tehtiin.
Monilla pk-yrityksillä nämä tiedot eivät ole täydellisessä muodossa. Yksityiskohdat voivat olla hajallaan chat-viesteissä, saapuneissa, tukipalvelun tiketeissä, kuvakaappauksissa ja tiimin jäsenten muistikuvissa. Yritykset pysyvät pinnalla poikkeaman aikana näiden tilkkutäkkimäisten tietojen avulla, mutta niistä tulee ongelma, kun valvontaviranomainen, vakuutusyhtiö, asiakas tai hallituksen jäsen pyytää selkeää aikajanaa.
Kaikenkokoiset yritykset tarvitsevat perusteellisen tietoturvapoikkeamalokin. Sen tulisi olla yksi totuuden lähde, johon kirjataan, mitä tapahtui, miten poikkeamaa käsiteltiin ja mitä todisteita päätösten tukena oli matkan varrella.
Tietue on arvokas, vaikka poikkeamaa ei tarvitsisi raportoida. Selitämme, miksi tietoturvapoikkeamalokit ovat hyödyllisiä yrityksellesi ja miten voit luoda omasi.
Miksi tietoturvapoikkeamalokit ovat tärkeitä
Poikkeamalokit vs. poikkeaman vastaussuunnitelmat
Mitä tietoturvapoikkeamalokin tulee sisältää
Yksinkertainen poikkeamalokipohja pk-yrityksille
Miten ilmoituspäätökset kirjataan
Mitä valvontaviranomaiset odottavat tietoturvapoikkeamalokeilta
Kirjautumistietojen käyttöloki
Miksi tietoturvapoikkeamalokit ovat tärkeitä
Tietoturvapoikkeamalokit luovat vastuullisuutta hetkellä, jolloin yritys todennäköisimmin menettää otteen yksityiskohdista. Poikkeaman aikana toimenpiteet tapahtuvat nopeasti: salasanat palautetaan, tilit poistetaan käytöstä, IT-palveluntarjoajiin otetaan yhteyttä, asiakastiedot tarkistetaan ja johtoa tiedotetaan. Nämä vaiheet voivat olla juuri se, mitä yritys tarvitsee sillä hetkellä, mutta niitä on paljon vaikeampi selittää myöhemmin, jos kukaan ei kirjaa, milloin kukin toimenpide tapahtui, kuka sen hyväksyi ja mitä todisteita päätöksen tukena oli.
Eurooppaan sijoittautuneille yrityksille tämä ei ole vain hyvää käytäntöä. Yleisen tietosuoja-asetuksen (GDPR) mukaan sekä Isossa-Britanniassa että EU:ssa henkilötietojen tietoturvaloukkaukset on arvioitava, ja osa niistä on ilmoitettava asianomaiselle valvontaviranomaiselle.
Isossa-Britanniassa ICO:n ilmoita tietoturvaloukkauksesta(uusi ikkuna) -ohjeessa selitetään, että organisaatioiden on arvioitava ihmisten oikeuksiin ja vapauksiin kohdistuva todennäköinen riski ja ilmoitettava ICO:lle, kun riski on todennäköinen. Artikla 33 edellyttää myös rekisterinpitäjiä dokumentoimaan henkilötietojen tietoturvaloukkaukset, mukaan lukien loukkauksen tosiasiat, sen vaikutukset ja toteutetut korjaavat toimenpiteet. Samat vaatimukset pätevät EU:n GDPR:n mukaisesti.
Esimerkiksi ICO ei odota jokaisella pk-yrityksellä olevan yritystason järjestelmiä, mutta se odottaa asianmukaisia tietoja. Sen tietoturvaloukkausten vastaamisen ja valvonnan viitekehys sanoo, että organisaatioilla tulisi olla menettelyt, joilla varmistetaan, että henkilötietoihin kohdistuvat poikkeamat ja tietoturvaloukkaukset havaitaan, hallitaan ja kirjataan asianmukaisesti. Tämä tarkoittaa, että poikkeamalokia ei pitäisi luoda vain silloin, kun vakava tietoturvaloukkaus on jo tapahtunut. Sen tulisi olla osa normaalia vastausprosessia.
Hyvät tietueet tukevat myös vakuutusvaatimuksia. Kybervakuuttajat voivat pyytää todisteita siitä, milloin poikkeama havaittiin, mitä rajoittamistoimenpiteitä toteutettiin, mitkä tilit olivat vaarantuneet ja noudattiko yritys poikkeaman vastausprosessiaan. Hyvin hoidettu loki voi osoittaa, että yritys toimi ripeästi ja johdonmukaisesti.
Se auttaa myös yritystä oppimaan. Muistikuvat ja suulliset tiedot eivät ole luotettavia, mutta tietue, joka osoittaa, että poikkeama alkoi uudelleenkäytetystä salasanasta, puuttuvasta monivaiheisesta tunnistautumisesta (MFA), toimittajan käyttöoikeuksista tai viivästyneestä käytöstä poistamisesta, antaa yritykselle konkreettista korjattavaa ja selkeämmän suunnan tietoturvan vahvistamiseen ajan myötä.
Poikkeamalokit vs. poikkeaman vastaussuunnitelmat
Tietoturvapoikkeamaloki ja poikkeaman vastaussuunnitelma liittyvät toisiinsa, mutta ne eivät ole sama asiakirja.
Poikkeaman vastaussuunnitelma selittää, mitä yrityksen tulisi tehdä, kun jotain menee pieleen. Siinä määritellään roolit, eskalaatioreitit, rajoittamistoimenpiteet, viestintävastuut ja palautumismenettelyt. Poikkeamaloki tallentaa, mitä todella tapahtui. Se on aikajana, todisteiden jäljitys, päätösten kirjaus ja seurantatiedosto tiettyä tapahtumaa varten.
Tällä erolla on väliä, koska hyväkin suunnitelma voi epäonnistua ilman dokumentointia. Yritys voi noudattaa oikeita vaiheita, mutta silti sen voi olla vaikea todistaa sitä myöhemmin. Lokin tulisi mahdollistaa käytännön kysymyksiin vastaaminen: milloin tiesimme, kuka toimi, mitä rajoitimme, mitkä tiedot olivat vaarassa, mitä päätimme ja mitä muuttui sen jälkeen?
| Poikkeaman vastaussuunnitelma: mitä yrityksesi tulisi tehdä | Tietoturvapoikkeamaloki: mitä todella tapahtui |
| Kuka johtaa vastausta Kuka ottaa yhteyttä IT:hen, lakiosastoon, vakuuttajaan tai viranomaisiin Miten rajoittaa, palautua ja viestiä | Milloin poikkeama havaittiin Mitkä järjestelmät ja tiedot olivat vaarantuneet Mitä toimenpiteitä tehtiin, kuka ne teki ja milloin |
Mitä tietoturvapoikkeamalokin tulee sisältää
Hyödyllisen poikkeamalokin on oltava riittävän johdonmukainen, jotta yritys voi jälkikäteen rekonstruoida tapahtuman ja selittää vastauksen aikana tehdyt päätökset.
Havaitsemispäivä ja -aika
Kirjaa, milloin yritys sai ensimmäisen kerran tiedon poikkeamasta, kuka sen huomasi ja miten se havaittiin. Jos aika on likimääräinen, merkitse se likimääräiseksi. Havaitsemisajalla on väliä, koska GDPR:n raportointiaikataulut ja vakuutusvaatimukset riippuvat usein siitä, milloin yritys sai tiedon ongelmasta.
Poikkeaman luonne
Kuvaile tapahtunut selkeällä kielellä. Vältä epämääräisiä tunnisteita, kuten “tietoturvaongelma” tai “mahdollinen tietoturvaloukkaus”, ilman kontekstia. Lokin tulisi selittää, mitkä järjestelmät olivat vaarantuneet ja liittyikö poikkeamaan kirjautumistietoja, sähköpostia, tiedostoja, asiakastietoja, maksujärjestelmiä, päätelaitteita vai ulkopuolisten tahojen käyttöoikeuksia.
Mukana olleet tiedot
Jos henkilötietoja on voinut vaarantua, kirjaa, minkä tyyppisiä tietoja oli mukana: nimiä, sähköpostiosoitteita, puhelinnumeroita, osoitteita, tilitietoja, taloudellisia tietoja, työntekijätietoja, asiakasviestintää, kirjautumistietoja tai muita olennaisia luokkia. Arvioi, kuinka moneen henkilöön se voi vaikuttaa, ja tee selväksi, onko luku vahvistettu vai vielä tutkinnassa.
Todennäköinen syy
Kirjaa tunnettu tai epäilty syy, vaikka tutkinta olisi vielä kesken. Kun uusia yksityiskohtia ilmenee, lokia voidaan päivittää tilasta “syy tuntematon” tilaan “tietojenkalastelusähköposti johti kirjautumistietojen vaarantumiseen” tai “entisen urakoitsijan tili pysyi aktiivisena”. Lokin tulisi osoittaa, miten yrityksen käsitys muuttui ajan myötä.
Välittömät rajoittamistoimenpiteet
Dokumentoi, mitä vahinkojen rajoittamiseksi tehtiin. Tähän voi sisältyä salasanojen palautuksia, istuntojen peruuttamisia, MFA:n käyttöönottoa, tilien keskeytyksiä, postilaatikon sääntöjen poistamisia, laitteiden eristämisiä, toimittajan käyttöoikeuksien poistamisia, palomuurimuutoksia tai väliaikaisia palvelun sulkemisia. Merkitse mahdollisuuksien mukaan kunkin toimenpiteen suorittaja ja aikaleima.
Ilmoituspäätökset
Kirjaa, ilmoittiko yritys asianomaiselle valvontaviranomaiselle (Isossa-Britanniassa ICO tai muualla EU:ssa kansalliselle tietosuojaviranomaiselle) asianosaisille henkilöille, asiakkaille, toimittajille, vakuutusyhtiöille, lakineuvojille tai lainvalvontaviranomaisille. Jos päätös oli olla ilmoittamatta, dokumentoi perustelut. Tämä selitys on usein yhtä tärkeä kuin itse ilmoitus.
Korjaavat toimenpiteet ja aikajana
Rajoittaminen käsittelee välitöntä poikkeamaa. Korjaaminen vähentää saman ongelman toistumisen mahdollisuutta. Kirjaa seurantatoimenpiteet, kuten MFA:n käyttöönotto, jaettujen kirjautumistietojen poistaminen, käyttöoikeuskäytäntöjen päivittäminen, käytöstä poistamisen parantaminen, virheellisen määrityksen korjaaminen tai varmuuskopioiden suojauksen muuttaminen.
Opitut asiat
Päätä siihen, mitä yritys oppi ja mitä muuttuu. Tätä ei tule kirjoittaa syyttävään sävyyn. Siinä tulisi yksilöidä heikkous, tarvittava parannus ja se, kuka vastaa seurannasta.
Yksinkertainen poikkeamalokipohja pk-yrityksille
Erikoisohjelmistot eivät ole välttämättömiä poikkeamien dokumentoinnissa. Laskentataulukko, suojattu sisäinen lomake, tikettijärjestelmä tai jaettu rekisteri voivat toimia, jos käyttöoikeuksia valvotaan ja merkinnät pidetään johdonmukaisina.
Tehokkaan poikkeamalokin tulisi sisältää seuraavat kentät:
- Poikkeaman tunnus: Yksilöllinen viitenumero.
- Havaitsemispäivä ja -aika: Milloin yritys sai tiedon poikkeamasta.
- Ilmoittaja: Työntekijä, palveluntarjoaja, asiakas, toimittaja, valvontahälytys tai ulkopuolinen taho.
- Poikkeaman tyyppi: Tietojenkalastelu, haittaohjelma, kirjautumistietojen vaarantuminen, tietojen menetys, luvaton pääsy, kiristyshaittaohjelma, toimittajapoikkeama, laitteen katoaminen, väärään osoitteeseen lähetetty sähköposti tai muu.
- Yhteenveto: Mitä tapahtui, kirjoitettuna selkokielellä.
- Vaikutuksen kohteena olevat järjestelmät: Osalliset sovellukset, tilit, laitteet, tietokannat, saapuneet-kansiot tai ulkopuolisten tahojen palvelut.
- Osalliset tiedot: Vaikuttiko asia henkilötietoihin, minkä tyyppisiin tietoihin ja kuinka moneen henkilöön se voi vaikuttaa.
- Todennäköinen syy: Tiedossa, epäilty tai tutkinnassa.
- Torjuntatoimet: Mitä tehtiin välittömästi.
- Ilmoituspäätös: Valvontaviranomainen, yksityishenkilöt, asiakkaat, vakuutusyhtiö tai ei ilmoitusta ja perustelut.
- Todisteiden linkit: Kuvankaappaukset, tiketit, lokit, sähköpostit, käyttölokit, vientitiedostot tai palveluntarjoajan raportit.
- Korjaavat toimet: Toimenpiteet torjunnan jälkeen.
- Vastuuhenkilö: Jatkotoimista vastaava henkilö.
- Tila: Avoin, valvonnassa, hallittu, ratkaistu, suljettu.
- Opitut asiat: Mitä pitäisi muuttaa.
Ilmoituspäätösten kirjaaminen
Ilmoituspäätökset ansaitsevat oman paikkansa tietoturvapoikkeamalokissa, koska niitä tarkastellaan usein poikkeaman jälkeen.
Sekä Ison-Britannian että EU:n GDPR:n mukaan organisaatioiden on arvioitava todennäköinen riski ihmisten oikeuksille ja vapauksille, kun henkilötietojen tietoturvaloukkaus tapahtuu. Jos riski on todennäköinen, valvontaviranomaiselle on ilmoitettava mahdollisimman pian ja, jos mahdollista, 72 tunnin kuluessa: Isossa-Britanniassa ICO(uusi ikkuna):lle ja kussakin EU:n jäsenvaltiossa kansalliselle tietosuojaviranomaiselle. Jos riski on suuri, myös asianomaisille henkilöille on ilmoitettava ilman aiheetonta viivytystä. Kynnysarvot ja määräajat ovat samat molemmilla puolilla; vain viranomainen vaihtuu.
Hyvän poikkeamalokin pitäisi näyttää, että yritys teki tämän arvion. Siinä pitäisi kirjata, oliko mukana henkilötietoja, millaista haittaa siitä voi aiheutua, mitä suojatoimia oli käytössä ja miksi yritys päätti ilmoittaa asiasta tai jättää ilmoittamatta.
Esimerkiksi poikkeama, johon liittyy paljastunut ylläpitäjän salasana, ei välttämättä paljasta heti, onko henkilötietoihin päästy käsiksi. Lokissa pitäisi näkyä tämä epävarmuus. Siihen voidaan kirjata alkuperäinen huoli, tutkinnan vaiheet, tilin toiminnan tarkastelu ja lopullinen johtopäätös, kun todisteita on saatavilla.
Tässä vaiheessa prosessia monet yritykset keskittyvät teknisen korjauksen hoitamiseen ja unohtavat kirjata vaatimustenmukaisuuden perustelut. Salasanat palautetaan, tilit suojataan ja toiminta jatkuu. Viikkoja myöhemmin yritys ei osaa selittää, miksi se päätti, ettei poikkeamasta tarvinnut ilmoittaa.
Mitä valvontaviranomaiset odottavat kirjauksilta
Valvontaviranomaiset eivät katso vain sitä, ilmoitettiinko tietoturvaloukkauksesta. Ne voivat myös kysyä, miten yritys:
- Tunnisti poikkeaman
- Arvioi riskin
- Päätti, tarvittiinko ilmoitus
- Dokumentoi toteutetut toimenpiteet
Hyvän kirjauksen pitäisi tehdä poikkeaman tarina selväksi alusta loppuun. Sen pitäisi näyttää, mitä tapahtui, mitä henkilötietoja oli mukana, millaista haittaa voi aiheutua, mitä yritys teki ongelman rajaamiseksi ja miksi se ilmoitti tietoturvaloukkauksesta tai jätti ilmoittamatta siitä.
Yksityiskohtaisuuden tason pitäisi vastata poikkeaman vakavuutta. Väärään osoitteeseen lähetetty sähköposti ei tarvitse samanlaista kirjausta kuin kiristyshaittaohjelmahyökkäys, mutta se on silti dokumentoitava, jotta voidaan näyttää, että yritys arvioi sen asianmukaisesti.
Nämä kirjaukset on myös tallennettava turvallisesti. Poikkeamalokit voivat sisältää arkaluonteisia tietoja asianomaisista henkilöistä, paljastuneista järjestelmistä, työntekijöiden toimista, kuvankaappauksia, käyttölokeja tai korjaavia toimenpiteitä. Käyttöoikeudet pitäisi rajoittaa henkilöihin, jotka niitä tarvitsevat, ja säilytyksen pitäisi olla linjassa yrityksen laajemman tietojen säilytyskäytännön kanssa.
Kirjautumistietojen käyttöloki
Monet poikkeamat liittyvät kirjautumistietoihin: ne voivat johtua uudelleenkäytetystä salasanasta, jaetusta tilistä, vaarantuneesta saapuneet-kansiosta, paljastuneesta ylläpitäjän kirjautumisesta, epäilyttävästä MFA-kehotuksesta tai työntekijästä, jota ei poistettu asianmukaisesti käytöstä.
Tästä syystä kirjautumistietojen käyttölokit voivat tulla suoraan syötteeksi kyberturvallisuuspoikkeamien dokumentointiin. Kun poikkeama liittyy jaettuun kirjautumiseen tai arkaluonteiseen tiliin, yrityksen on tiedettävä, kellä oli käyttöoikeus, miten käyttöoikeus jaettiin, muuttuivatko käyttöoikeudet ja vaihdettiinko kirjautumistiedot poikkeaman jälkeen.
Yrityksen salasananhallinta, kuten Proton Pass for Business, auttaa tiimejä hallitsemaan kirjautumistietoja salatuissa holveissa, luomaan yksilöllisiä salasanoja, käyttämään automaattitäyttöä, jakamaan kirjautumistietoja turvallisesti, hallitsemaan pääsyavaimia ja käyttämään sisäänrakennettua kaksivaiheista tunnistautumista. Poikkeamien dokumentoinnissa arvokkainta on kirjautumistietoihin liittyvä käyttöpolku: kellä oli käyttöoikeus jaettuihin holveihin/tileihin, miten käyttöoikeutta hallittiin ja kuka sitä käytti, sekä mikä muuttui poikkeaman jälkeen.
IT-tiimien salasananhallinta tuo mukanaan ylläpitäjän ominaisuuksia, kuten käytännöt, raportoinnin, lokit, tehtäväpohjaisen käyttöoikeuksien hallinnan, SCIM-käyttöönoton ja SSO-integroinnin. Nämä ominaisuudet voivat auttaa yrityksiä näyttämään, miten kirjautumistietojen käyttöä valvotaan, ja tarjoamaan todisteita, kun kirjautumistietoihin liittyvää poikkeamaa tutkitaan.
Salasananhallinta ei voi korvata poikkeamalokia, oikeudellista arviota, sääntelyyn liittyvää ilmoitusprosessia tai poikkeamien hallintasuunnitelmaa. Se voi kuitenkin tarjota kirjautumistietoihin liittyviä todisteita, joita voidaan hyödyntää näissä prosesseissa.
Ylläpidä kattavaa käyttöpolkua kirjautumistietojen käytöstä yrityksen salasananhallinnalla.
