Jos koodi on Gitissä, käyttöoikeudet ovat roolipohjaisia ja lokit sekä varmuuskopiot ovat kunnossa, olette ISO 27001:n näkökulmasta jo pitkällä. Kirjoitin aiemmin siitä, miksi sertifiointi kannattaa ohjelmistoyrityksessä. Tällä kertaa avaan toisenlaisen näkökulman.
Auditoin vuosittain kymmeniä erilaisia organisaatioita ja IT-yritykset erottuvat astetta paremmalla valmiudellaan sertifiointiin. ISO 27001:n edellyttämiä kontrolleja — siis standardin liitteen A mukaisia toimenpiteitä — on yleensä jo kosolti asianmukaisesti käytössä.
Sertifioinnissa suurin puuttuva palanen on hallintajärjestelmä eli standardin vaatimusten 4–10 kuvaama kokonaisuus, jolla riskejä ja tietoturvaa hallitaan ja johdetaan järjestelmällisesti. Liian suuri osa tietoturvasta on jäänyt yksittäisten asiantuntijoiden vastuulle.
Edellä kuvattu muuttaa sitä, millaiseksi sertifiointiprojekti käytännössä muovautuu.
Mitä ISO 27001:n kontrolleista on IT-yrityksessä jo valmiina?
IT-alan yritysten arkeen kuuluu paljon sellaista, mitä standardin liite A edellyttää — mutta mitä ei välttämättä osata edes mieltää tietoturvakontrolleiksi.
Versionhallinta on hyvä esimerkki. Lähes jokaisessa ohjelmistoyrityksessä koodi on Gitissä, muutokset ovat jäljitettävissä ja tuotantoon vienti tapahtuu hallitun prosessin kautta. Standardin näkökulmasta tämä vastaa isoa osaa muutoksenhallinnasta ja se on yksi keskeisimmistä kontrolleista.
Pääsynhallinta on toinen alue, jossa on usein tehty paljon. Pilvipalveluiden käyttö on pakottanut IT-yritykset miettimään, kenellä on pääsy mihinkin. Roolipohjainen pääsynhallinta, kaksivaiheinen tunnistautuminen ja palvelukohtaiset käyttöoikeudet ovat monessa yrityksessä arkipäivää — ja juuri sitä, mitä standardi vaatii.
Lisäksi lokien kerääminen ja monitorointi, varmuuskopiointi, kehitys- ja tuotantoympäristöjen erottaminen sekä koodikatselmoinnit ovat kaikki käytäntöjä, jotka ovat IT-alalla peruskauraa. Niitä ei ole rakennettu standardia varten, mutta ne istuvat siihen kuin nenä päähän.
Tietoturvallisuuden hallintajärjestelmä on suurin savotta
Kun kontrollit ovat kunnossa, sertifiointiprojektin painopiste siirtyy hallintajärjestelmään.
Konkreettisesti kyse on kolmesta asiasta.
1. Riskienhallinta
IT-yrityksissä riskit kyllä tunnistetaan, mutta harvoin riittävän järjestelmällisesti. Kehittäjät tietävät, mitkä palvelut ovat herkkiä, ja moni kehittäjistä on tunnistanut jopa haavoittuvuuksia, mutta tätä tietoa ei ole koottu yhteen eikä sitä arvioida säännöllisesti. Standardi edellyttää, että riskit tunnistetaan, arvioidaan, priorisoidaan ja käsitellään dokumentoidusti — ja että tätä tehdään jatkuvasti.
2. Johdon rooli
Tietoturva on usein IT-päällikön harteilla. Standardi kuitenkin edellyttää, että myös johto on sitoutunut tietoturvan hallintaan sekä määritellyt vastuut ja varmistanut resurssit. Tämä ei tarkoita, että toimitusjohtajan pitäisi ymmärtää jokainen tekninen yksityiskohta. Se tarkoittaa, että tietoturvan on oltava johdon agendalla ja että päätökset tehdään tietoisesti.
3. Jatkuva mittaaminen, seuranta ja kehittäminen
Hallintajärjestelmä edellyttää, että tietoturvan toteutumista mitataan ja seurataan järjestelmällisesti. Käytännössä tämä tarkoittaa mittariston rakentamista, säännöllistä sisäistä auditointia, johdon katselmointeja sekä havaittuihin poikkeamiin reagointia ja niiden korjaamista. IT-yrityksissä tietoturvaa seurataan usein teknisillä mittareilla, mutta hallintajärjestelmätason seuranta, eli toimiiko kokonaisuus, reagoidaanko poikkeamiin, kehittyykö toiminta, jää vähemmälle tai tekemättä.
Lisäksi toimittajien hallinta, joka on standardin liitteen A kontrolli, on monelle kehittämisen kohta, johon olisi hyvä investoida. Pilvipalvelut, kirjastot, avoimen lähdekoodin komponentit ja ulkoistettu sovelluskehitys ovat tyypillisiä toiminnan osa-alueita, mutta niiden tietoturvatason järjestelmällinen arviointi ja seuranta saattavat jäädä heikoksi.
Miten ISO 27001 -sertifiointiprojekti etenee käytännössä?
Kun IT-talo lähtee hakemaan sertifiointia, projektin painopiste siirtyy nopeasti sinne, missä savottaa on jäljellä, eli hallintajärjestelmän rakentamiseen, tukeutuen jo olemassa oleviin käytäntöihin.
Sertifiointiprojekti etenee tyypillisesti neljässä vaiheessa:
- Ensin kartoitetaan nykytilanne ja tunnistetaan, mitä meillä jo on olemassa ja mitä puuttuu. Tämä niin sanottu gap-analyysi on ollut monelle IT-yritykselle positiivinen kokemus. Jos standardin liitteen A kontrolleista suuri osa on kunnossa, voidaan keskittyä standardin vaatimuksiin 4–10.
- Toisessa vaiheessa rakennetaan puuttuvat osat eli tarkennetaan riskienhallintaprosessia ja dokumentaatiota, määritellään johdon katselmointikäytännöt sekä otetaan käyttöön puuttuvat hallintakeinot. Nämä kytketään osaksi arjen toimintaa ja yritykselle luontevaa johtamisjärjestelmää.
- Seuraavaksi vuorossa on sisäinen auditointi ja johdon katselmointi.
- Lopuksi tehdään varsinainen sertifiointiauditointi. Moni organisaatio hyödyntää ennen sitä esiauditointia, jossa auditoija käy hallintajärjestelmän läpi ja tunnistaa mahdolliset puutteet ennen varsinaista sertifiointipäätöstä.
IT-yrityksessä tämä prosessi kestää tyypillisesti 3–6 kuukautta, kun monilla muilla toimialoilla aikaa voi kulua helposti kaksinkertaisesti. Automaatiotyökalut, kuten Vanta, nopeuttavat prosessia entisestään — esimerkiksi hallintajärjestelmän ylläpitoa ja todisteiden (evidenssin) keräämistä voidaan suurelta osin automatisoida.
Valmista ei tule koskaan, eikä tarvitsekaan
ISO 27001 ei edellytä täydellisyyttä. Se edellyttää järjestelmällistä tapaa tunnistaa puutteet, arvioida riskit ja parantaa toimintaa jatkuvasti. IT-alan yrityksissä tämä ajattelumalli on tuttu. Se on käytännössä sukua iteratiiviselle kehitykselle, jossa tavoitteena on tulla koko ajan hieman paremmaksi siinä, mitä teette.
Sertifiointi on lähtökohta, josta järjestelmällinen kehittäminen alkaa. Ensimmäisessä auditoinnissa ei tarvitse olla valmis. Riittää, kun on järjestelmällinen.
Jos edellinen kirjoitukseni sai pohtimaan, kannattaisiko teidän lähteä sertifiointipolulle, tämä IT-yrityksiä koskeva huomioni toivottavasti kannustaa siihen. Tekniset kontrollit ovat todennäköisesti jo suurelta osin kunnossa. Rakennetaan hallintajärjestelmä ja työmäärä on pienempi kuin ehkä kuvittelit.
Jos asia on ajankohtainen, soita tai viesti. Autan mielelläni.
Ville
Ville Koskinen on Into Securityn operatiivinen johtaja, pääauditoija ja perustajaosakas. Hän auditoi vuosittain kymmeniä organisaatioita ja on erikoistunut tietoturvallisuuden kokonaisvaltaiseen hallintaan ja kehittämiseen.