Siirry sisältöön
Legiscope
Valikko
Tietosuoja

Kyberriskien arviointi: uhkaskenaarioista toimenpiteisiin

Kyberriskien arviointi viidessä vaiheessa: täytetty toimittajaskenaario, riskiluokitus, toimenpiteet ja käyttöönottopäätös.

Kyberriskien arviointi auttaa päättämään, mitä suojataan ensin ja millainen näyttö riittää toimenpiteen valmistumisesta. Pelkkä luettelo haittaohjelmista, tietovuodoista ja palvelukatkoista jää liian yleiseksi. Käyttökelpoinen arvio kuvaa tapahtumaketjun, sen edellytykset, seuraukset ja ne kohdat, joissa organisaatio voi katkaista ketjun.

Tässä oppaassa seurataan kuvitteellista Tilapalvelu Aava Oy:tä, joka ottaa käyttöön kiinteistöhuollon työnohjauspalvelun. Asiakkaiden yhteystiedot, huoneistokohtaiset huoltopyynnöt ja asentajien työjonot siirtyvät samaan järjestelmään. Esimerkki näyttää, miten ulkoisen ylläpidon käyttöoikeuksiin liittyvä uhka muutetaan perustelluksi käyttöönottopäätökseksi.

Menetelmä tukee päätöstä, mutta ei korvaa sitä

Ranskan kyberturvallisuusviranomaisen ANSSI:n EBIOS Risk Manager yhdistää turvallisuuden perustason tarkastelun ja tahallisiin, kohdennettuihin uhkiin keskittyvät skenaariot. Sen viisi työpajaa käsittelevät rajauksen ja perustason, riskin lähteet, strategiset skenaariot, operatiiviset skenaariot sekä riskin käsittelyn. Tässä käytetään tätä etenemisjärjestystä kevennetyn harjoituksen runkona. ANSSI:n menetelmäkuvaus.

Menetelmän nimi ei tee arvioinnista Suomessa lakisääteisesti riittävää eikä tarkoita, että organisaation pitäisi käyttää juuri EBIOS RM:ää. GDPR:n 32 artiklassa ratkaisee riskiä vastaava turvallisuus. Mahdollisen NIS2-sääntelyn soveltuminen ja siitä seuraavat velvoitteet arvioidaan erikseen Suomen NIS2-riskienhallinnan kokonaisuudessa.

Myös tahattomat virheet, laiterikot ja fyysiset häiriöt tarvitsevat käsittelyn. Niitä ei pidä väkisin kuvata motivoituneen hyökkääjän toimintana. Traficomin uhka-analyysiohje korostaa kaikkien vaaratekijöiden huomioimista ja realististen tapahtumaketjujen arviointia. Sen avulla erotetaan järjestelmän hyökkäyspinnat, uhkien vaikutukset ja soveltuvat hallintakeinot. Traficomin uhka-analyysiä ja uhkamallinnusta koskeva ohje.

1. Rajaa toiminta ja kuvaa pelätty seuraus

Aava rajaa arvioinnin uuden huoltopyynnön vastaanottamisesta työn kuittaukseen ja laskutusperusteen muodostamiseen. Palkanlaskenta jää ulkopuolelle. Rajaus ei silti katkaise riippuvuuksia: työntekijöiden tunnistuspalvelu, ylläpitoyhtiö ja viestipalvelu kuuluvat arvioon siltä osin kuin niiden häiriö vaikuttaa työnohjaukseen.

Työpajaan osallistuvat huoltopäällikkö, järjestelmästä vastaava ylläpitäjä, hankinnoista vastaava henkilö ja tietosuojan asiantuntija. Huoltopäällikkö osaa kuvata, milloin virheellinen työjono vaarantaa asiakkaiden arjen. Ylläpitäjä selvittää tekniset reitit. Hankinta tuntee toimittajan sopimuksen. Kukaan heistä ei yksin näe koko tapahtumaketjua.

Pelätty seuraus kirjoitetaan täsmällisesti: ”Huoneistokohtaiset huoltopyynnöt ja yhteystiedot kopioidaan ulkopuoliselle, ja työjonojen muutokset estävät kiireellisten vuotojen korjauksen.” Tämä sisältää sekä luottamuksellisuuden että eheyden ja saatavuuden. Pelkkä ”mainehaitta” ei kerro, ketä vahingoitetaan tai mitä toimintoa pitää turvata.

Taustalle valmistellaan järjestelmäkartoitus. Siihen merkitään, missä tiedot ovat, kuka niitä voi muuttaa ja mikä palvelu välittää kirjautumisen. Aava huomaa jo tässä vaiheessa, että yhden ylläpitotunnuksen voi käyttää sekä asiakasrekisterin vientiin että varmuuskopioiden poistamiseen. Tämä havainto kirjataan perustason puutteeksi odottamatta kaikkien työpajojen valmistumista.

2. Valitse uhkatoimija ja tavoite perustellusti

Aava tarkastelee kahta tahallista uhkaa: rahallista hyötyä tavoittelevaa rikollista, joka saa haltuunsa toimittajan ylläpitotunnuksen, sekä toimittajan työntekijää, joka käyttää oikeuksiaan väärin. Näiden edellytykset eroavat. Ensimmäisessä kirjautumisen suojaus voi katkaista reitin; toisessa aito käyttäjä on jo valtuutettu, joten tehtävien erottaminen ja toiminnan seuranta korostuvat.

Yritys ei lisää valtiollista vakoilua tärkeimmäksi skenaarioksi pelkästään siksi, että se esiintyy uhkaluettelossa. Asiakkaat, tiedot ja havaittu pääsyreitti eivät tässä harjoituksessa anna tälle ensisijaisuutta. Rajaus dokumentoidaan niin, että se voidaan avata myöhemmin, jos asiakaskuntaan tulee esimerkiksi erityisen suojattavia kohteita.

Toimittajan asentajan erehdys tuotantoympäristön valinnassa kirjataan erilliseksi tahattoman muutoksen riskiksi. Sen hallintakeinoksi ei riitä rikollisen tunnistaminen. Tuotanto- ja koeympäristön erottaminen, muutoksen ennakkotarkistus ja palautusmahdollisuus käsittelevät juuri tätä virhettä.

3. Kuvaa reitti yhteistyökumppanin kautta

Strateginen skenaario yhdistää uhkatoimijan tavoitteen organisaation riippuvuuksiin. Aavan esimerkissä rikollinen pyrkii kiristykseen varastamalla asiakastietoja ja häiritsemällä palvelua. Reitti kulkee ulkoisen ylläpitäjän kautta, koska tällä on laajat oikeudet useiden asiakkaiden ympäristöihin.

Toimittajan tunnettu nimi tai yleinen turvallisuusvakuutus ei ratkaise, millainen pääsy sillä on juuri Aavan tietoihin. Hankinta pyytää kuvauksen tunnusten henkilökohtaisuudesta, korotettujen oikeuksien myöntämisestä ja asiakkaan mahdollisuudesta peruuttaa pääsy. Käsittelijän ja rekisterinpitäjän roolien selvittäminen sekä tarvittava käsittelysopimus täydentävät teknistä tarkastelua.

Aava saa vastauksen, että päivittäinen tuki ja korotettu ylläpito käyttävät samaa pysyvää ryhmää. Tätä pidetään todellisena tietona. Sen sijaan toimittajan ilmoitus ”kaikki tapahtumat lokitetaan” jää vielä varmistettavaksi: se ei kerro, tallentuuko asiakastietojen massavienti tai kuka seuraa tapahtumia.

4. Muuta reitti tarkistettavaksi tapahtumaketjuksi

Operatiivinen skenaario tekee näkyväksi, mihin hallintakeino kohdistuu. Esimerkin ketju ei ole hyökkäyksen toteutusohje, vaan puolustuksen arviointiin käytettävä kuvaus oikeuksista ja niiden vaikutuksista.

Ketjun vaihe Havaittu edellytys Tarkistettava suojaus
Ulkopuolinen saa käyttöönsä ylläpitotunnuksen Pysyvä laaja tunnus, palautusmenettely epäselvä Henkilökohtaisuus, vahva tunnistus ja palautuksen varmistus
Tunnus avaa Aavan tuotantoympäristön Sama ryhmä usealle asiakkaalle Asiakaskohtainen rajaus ja määräaikainen oikeus
Asiakastiedot voidaan viedä tiedostoon Tuki voi käyttää vientitoimintoa Vientioikeuden erottaminen tavallisesta tuesta
Häiriön jälkiä tai palautusta voidaan heikentää Sama rooli hallitsee kopioita ja tapahtumia Erillinen hallinta ja suojattu tapahtumaseuranta

Arvioija merkitsee jokaiseen kohtaan tiedon varmuuden. Ryhmäjäsenyys on nähty asetuksista. Vientioikeutta on kokeiltu sovitulla testitunnuksella. Kopioiden poistamisen estoa ei ole vielä todettu. Siksi tätä suojausta ei lasketa nykyiseen turvallisuustasoon pelkän suunnitelman perusteella.

Salasanapolitiikan ja MFA:n tarkastelussa huomioidaan myös tilin palautus. Vahva kirjautuminen menettää merkitystään, jos helpdesk antaa uuden kirjautumisvälineen heikosti varmennetulle soittajalle. Lokituksen osalta täytetty vaatimus on ”asiakastietojen vientitapahtuma tunnistetaan ja vastuuhenkilö saa siitä ilmoituksen”, ei yleinen ”lisätään valvontaa”.

Vakavuus ja todennäköisyys tarvitsevat sanallisen perustelun

Aava käyttää omaa kolmiportaista luokitusta: vähäinen, merkittävä ja vakava. Vakava seuraus tarkoittaa tässä esimerkiksi sellaista työnohjauksen menetystä, joka estää kiireellisten tehtävien turvallisen hoitamisen, tai laajaa huoneistokohtaisten tietojen paljastumista. Luokat eivät ole viranomaisen yleisiä raja-arvoja.

Arvioitu toteutumisen uskottavuus on ennen korjauksia merkittävä, koska pääsy on jatkuva ja oikeuksien kasautuminen on todettu. Tiimi ei kirjoita vuosittaista prosenttia ilman havaintoaineistoa. Se kirjaa myös epävarmuuden: toimittajan palautusmenettelyä ja asiakkaiden välistä rajausta ei tunneta riittävästi.

Pelkkä luokkanumeroiden kertominen ei osoita riskin suuruutta. Kaksi samalla värillä merkittyä riskiä voi edellyttää eri päätöstä, jos toisessa seurauksena on peruuttamaton tietojen paljastuminen ja toisessa nopeasti korjattava käyttökatko. Aavan johto näkee siksi päätöstaulukossa luokan lisäksi tapahtumaketjun ja ihmisiin kohdistuvat seuraukset.

5. Päätä toimenpiteet ja käyttöönottoraja

Aava vähentää riskiä kolmella toimenpiteellä: ylläpito rajataan asiakaskohtaiseksi, vientioikeus poistetaan tavalliselta tukiroolilta ja varmuuskopioiden hallinta erotetaan tuotannon ylläpidosta. Tavoitteet kytketään tietoturvapolitiikkaan, mutta niiden valmistuminen osoitetaan erillisillä havainnoilla.

Ensimmäinen päätös kuuluu: ”Tuotantokäyttöä ei aloiteta ennen kuin asiakaskohtainen rajaus ja palautuksen erottaminen on todennettu.” Hankintavastaava pyytää toimittajalta toteutuksen, tekninen vastuuhenkilö tarkistaa sen ja huoltopäällikkö hyväksyy toimintamallin. Kalenteriin asetettu päivämäärä ei yksin muuta keskeneräistä suojausta valmiiksi.

Todentamisessa tavallinen tukitunnus ei enää pääse vientitoimintoon. Korotetun ylläpidon pääsy päättyy sovitun työjakson jälkeen. Varmuuskopion palautus onnistuu erillisellä roolilla myös silloin, kun tuotannon ylläpitotunnus on suljettu. Havaintojen jälkeen uudelleenarvioitu skenaario kirjataan pienemmän uskottavuuden luokkaan; tietojen paljastumisen vakavuutta ei alenneta vain siksi, että estotoimia lisättiin.

Vakuutus tai toimittajan korvausvastuu voi jakaa taloudellisia seurauksia, mutta se ei palauta jo paljastuneita henkilötietoja salaisiksi. Myöskään johdon allekirjoitus ei anna lupaa sivuuttaa lain vaatimusta. Hyväksyttävä jäännösriski ja lainmukainen käsittely ovat toisiinsa liittyviä mutta erillisiä kysymyksiä.

Milloin tarvitaan lisäksi tietosuojan vaikutustenarviointi?

Tietoturva-arvio tarkastelee vain osaa henkilötietojen käsittelyn riskeistä. Aavan järjestelmä voisi olla teknisesti suojattu mutta silti kerätä huoltopyyntöihin tarpeettomia terveystietoja tai mahdollistaa työntekijöiden suhteettoman seurannan. Näitä ongelmia ei ratkaista kirjautumisen vahvistamisella.

Tietosuojan vaikutustenarvioinnissa tarkastellaan käsittelyn kuvausta, tarpeellisuutta ja oikeasuhteisuutta, ihmisten oikeuksiin ja vapauksiin kohdistuvia riskejä sekä niitä käsitteleviä toimia. Jos korkea riski jäisi ilman riittäviä toimenpiteitä, ennakkokuulemisen tarve ratkaistaan ennen käsittelyä. Tietosuojavaltuutetun vaikutustenarviointiohje ja GDPR:n 35–36 artikla erottavat tämän velvoitteen tavallisesta yritysriskin hyväksymisestä.

Aava arvioi tarpeen vaikutustenarvioinnin menettelyllä. Kyberskenaarion tulokset voidaan käyttää sen turvallisuusosassa, mutta muut osat laaditaan käsittelyn todellisen tarkoituksen mukaan. ANSSI:n menetelmäopas ja työpohjat voivat tukea työpajoja; niiden käyttäminen ei itsessään osoita kaikkien GDPR-vaatimusten täyttymistä.

Päivitä arvio, kun oletus muuttuu

Kolmen kuukauden kuluttua toimittaja ehdottaa keskitettyä ylläpitotunnusta nopeampaa yöpäivystystä varten. Se muuttaa aiemmin hyväksyttyä asiakaskohtaista rajausta. Aava avaa kyseisen skenaarion uudelleen ja pyytää vaihtoehdon, joka säilyttää rajauksen. Koko raporttia ei tarvitse kirjoittaa tyhjästä, mutta vanhaa hyväksyntää ei sovelleta muuttuneeseen pääsyreittiin.

Seurannan hyödyllisiä kohteita ovat keskeneräiset toimet, uudet oikeusryhmät, toteutuneet häiriöt ja palautusharjoitusten havainnot. Näin arvioinnin lopputulos säilyy päätöksenteon välineenä: johto tietää, mikä riski on edelleen avoin, mihin oletukseen hyväksyntä perustuu ja kuka reagoi oletuksen rikkoutumiseen.

L
Kirjoittanut
Legiscope
Legiscope

Vie ohjeistus käytäntöön

Katso, miten Legiscope yhdistää tietosuojarekisterit, lähdeaineiston ja tarkastettavan työn.

Varaa räätälöity esittely
Jatka lukemista

Aiheeseen liittyvät artikkelit

01Tietosuoja

Automaattinen henkilötietojen käsittely ja GDPR:n soveltamisala

GDPR:n tarkoittama automaattinen henkilötietojen käsittely ei edellytä tekoälyä, robottia tai koneen itsenäistä päätöstä. Tavallinen asiakastietojen tallentaminen tietokoneelle voi kuulua sen…

8. syyskuuta 2026
02Tietosuoja

Automaattiset päätökset: GDPR 22 artiklan rajat ja suojatoimet

GDPR:n 22 artikla koskee päätöksiä, jotka perustuvat pelkästään automaattiseen käsittelyyn ja joilla on henkilöön kohdistuvia oikeusvaikutuksia tai vastaavalla tavalla merkittäviä vaikutuksia. Kyse…

8. syyskuuta 2026
03Tietosuoja

DORA Suomessa 2026: Finanssivalvonta ja digitaalinen häiriönsietokyky

DORA-asetusta on Suomessa sovellettu 17.1.2025 alkaen ilman siirtymäaikaa, ja sen toteutumista valvoo Finanssivalvonta. Asetus koskee yli 400 valvottavaa toimijaa: pankkeja, vakuutusyhtiöitä,…

4. heinäkuuta 2026
04Tietosuoja

Erityiset henkilötietoryhmät: GDPR 9 artiklan käsittelyehdot

Erityisiin henkilötietoryhmiin kuuluvien tietojen käsittely on lähtökohtaisesti kielletty. GDPR:n 9 artikla sisältää poikkeukset tähän kieltoon. Organisaation on tunnistettava sekä soveltuva poikkeus…

8. syyskuuta 2026
05Tietosuoja

GDPR 12 artikla: selkeä informointi ja tietopyyntöjen käsittely

GDPR:n 12 artikla määrää, miten rekisterinpitäjä kertoo henkilötietojen käsittelystä ja auttaa ihmisiä käyttämään oikeuksiaan. Tiedot on annettava selkeästi, ymmärrettävästi ja helposti saatavilla.…

8. syyskuuta 2026
06Tietosuoja

GDPR 14 artikla: muualta kerättyjen tietojen informointi

Yritys saa uuden yhteyshenkilön tiedot sopimuskumppanilta, täydentää asiakasrekisteriä julkisesta lähteestä tai ostaa ammatillisia yhteystietoja. Henkilö ei itse täyttänyt yrityksen lomaketta, mutta…

8. syyskuuta 2026
07Tietosuoja

GDPR-ohjelmisto pk-yrityksille 2026: valinta, ominaisuudet ja hinnat

Pk-yritykselle paras GDPR-ohjelmisto on kevyt, EU-isännöity alusta, joka automatisoi käsittelytoimien selosteen, tietopyynnöt ja käsittelysopimukset ilman kokopäiväisen tietosuojatiimin tarvetta.…

4. heinäkuuta 2026
08Tietosuoja

GDPR-ohjelmiston hinta 2026: mitä tietosuojaohjelmisto maksaa?

Hinta ei ole pelkkä kuukausilisenssi. Kokonaiskustannus (TCO) muodostuu neljästä osasta:

4. heinäkuuta 2026