Kyberkestävyyssäädöksen (CRA) 11. syyskuuta 2026 voimaan astuva ilmoitusvelvollisuus edellyttää yrityksiltä asioita, jotka voidaan paljolti ratkaista sopimalla: nimetään ilmoituksista vastaava henkilö ja hänelle varahenkilö, valmistaudutaan rekisteröitymään ENISAn Single Reporting Platform -alustalle sen avauduttua ja määritellään miten poikkeamatilanteet voidaan havaita kohtuullisessa ajassa, oli kyseessä viikonloppu, kesälomakausi tai normaali syksyinen arkipäivä.
Traficom tarkensi ohjeistusta 26. elokuuta, ja toistaiseksi virallisen ilmoituksen voi tehdä vain näiden kahden nimetyn henkilön tunnuksilla.
11. joulukuuta 2027 voimaan tulee lisää vaatimuksia ja ne ovatkin toista maata. Tuolloin markkinoille saatettavien digitaalisten tuotteiden on täytettävä CRA:n kyberturvallisuusvaatimukset, joihin kuuluvat muun muassa turvallinen suunnittelu ja turvalliset oletusasetukset – secure by design ja secure by default. Näissä ei riitä sopiminen, vaan nyt mennään siihen, miten tuote rakennetaan.
Teknologiayhtiön kehitysprosessin muuttaminen vie helposti enemmän aikaa kuin äkkiseltään kuvittelisi, ja joulukuukin tulee nopeasti vastaan.
Listan 22 kohtaa ja miten valita oleelliset
Otetaan avuksi ENISAn heinäkuun lopussa julkaisema, pk-yrityksille suunnattu “Secure by Design and Default Playbook” -opas. Se on ilmainen, ja löytyy GitHubista. Osia siinä on peräti 22, ja voi olla haasteellista valita marssijärjestys.
Valitsisin aloitukseen alla olevat neljä kohtaa, jotka istuvat myös ENISAn ehdottamaan etenemisjärjestykseen. Siinä uhkamallinnus on ensimmäisen vaiheen lähtöpiste, ja kolme muuta kuuluu seuraavan vaiheen perustason käytäntöihin.
Auditoijan näkökulmasta näissä on lisäksi hyödyllinen ominaisuus: ne synnyttävät konkreettista näyttöä, jonka voi todentaa.
1. Luottamusrajat ja uhkamallinnus (oppaan osa 1).
Kertoo, että joku on käyttänyt aikaa sen miettimiseen, mistä hyökkäys voisi tulla. Näyttönä voi olla esimerkiksi päivätty uhkamalli, arkkitehtuuri- tai tietovirtakuva luottamusrajoineen, nimetyt osallistujat sekä lista tunnistetuista ja priorisoiduista uhista.
2. Haavoittuvuuksien ja päivitysten hallinta (osa 13).
Tämä on sama ketju, jota syyskuun ilmoitusvelvollisuus jo vaatii, joten se kannattaa rakentaa kerralla kunnolla. Näyttönä tässä ovat esimerkiksi haavoittuvuusrekisteri, sovitut käsittelyajat sekä jälki siitä, milloin haavoittuvuus havaittiin, korjattiin ja korjaus lähti asiakkaille.
3. Toimitusketjun hallinta (osa 14).
Tarkoittaa käytännössä sitä, että tiedätte, mitä komponentteja tuotteessanne on. Ilman ajantasaista komponenttiluetteloa – esimerkiksi SBOMia (Software Bill of Materials) – on hyvin vaikea arvioida, koskeeko uusi haavoittuvuus teitä. Näyttönä on esimerkiksi julkaisukohtainen SBOM sekä tieto siitä, milloin se on muodostettu tai päivitetty.
Toimitusketjuun kuuluvat myös alihankkijat, jotka kehittävät koodia suoraan tuotteeseenne. Tällöin kyse ei ole ostetusta komponentista, vaan palveluntarjoajasta, jonka tietoturva on syytä varmistaa jo sopimustasolla. Näyttönä toimivat sopimusehdot, joissa tietoturvavaatimukset ulottuvat toimittajaan asti.
4. Tiukat oletusoikeudet (osa 16 oletusasetusten tiukentamisesta).
Tuote toimitetaan suppeimmilla oikeuksilla, joilla sitä voi käyttää, ja asiakas avaa tarvitsemansa lisäoikeudet itse. Tässä moni suomalainen ohjelmistotalo pärjää jo varsin hyvin, mutta ei välttämättä ole kirjannut sitä mihinkään. Näyttönä on oletusasetusten kuvaus ja perustelu siitä, miksi ne on valittu.
Mikä kelpaa todisteeksi?
Auditoinnissa hyvin tavanomainen tilanne on se, että ohjeissa lukee, että jokaisella käyttäjällä ja järjestelmällä on vain ne oikeudet, joita työn tekeminen vaatii. Käytännössä hyvin harva on auditointitilanteessa osannut näyttää minulle edes yhtä tapausta, jossa linjaus on oikeasti ohjannut toimintaa.
Todisteeksi kelpaa vain selkeä näyttö. Esimerkkejä tästä ovat:
- Katselmointimerkintä, jossa joku on huomannut liian laajat oikeudet ja vaatinut niiden korjaamista – ja korjaustoimet suoritettu.
- Automaattinen tarkistus, joka pysäyttää julkaisun, kun komponentista löytyy tunnettu haavoittuvuus.
- Julkaisumuistio, josta näkyy, mitä tarkistettiin ennen version julkaisua.
Jotta tähän päästään, prosessin on oltava kunnossa. Ja sellaisen rakentaminen kestää.
Ehdotukseni on, että valitsette aluksi tuotteestanne yhden selkeän kokonaisuuden ja teette sille uhkamallinnuksen huolellisesti. Kun dokumentoitte sen kunnolla, näette selkeästi, mitkä asiat teillä on jo hallussa ja mitä mahdollisesti puuttuu. Huolellinen pohdinta ja hyvä dokumentointi kertovat valmiudestanne enemmän kuin koko lista kerralla luettuna.
Jos haluatte nähdä, miltä tulos näyttää auditoijan silmin, käydään se yhdessä läpi.
Ville Koskinen
COO & Lead Auditor
Aiempi kirjoitukseni samasta aiheesta: Kyberkestävyyssäädöksen ilmoitusvelvollisuus
Blogin kuvituskuvan laadinnassa on käytetty teköälyä.