Ohjelmistojen tietoturvariskien arviointi

Tämän blogisarjan aiemmissa osissa olemme käsitelleet ohjelmistojen tietoturvallisuutta kehitysprosessin ja tietoturvavaatimusten näkökulmasta. Kolmannessa osassa keskitymme ohjelmistojen tietoturvariskien arviointiin.

Tieto- ja kyberturvallisuudenhallintamenetelmät perustuvat nykyisin pitkälti riskiarvioinnin käyttämiseen. Riskiarvioinnin tavoitteena on mitoittaa suojaustoimenpiteet tunnistettuihin uhkiin ja niiden vaikutuksiin. Käytännössä missään organisaatiossa tai projektissa eivät resurssit riitä toteuttamaan aukotonta turvallisuutta, joten riskiarvioinnin kautta pyritään löytämään ne vastatoimenpiteet, joiden kautta saavutetaan paras mahdollinen vaikuttavuus tunnistettuja uhkia vastaan. Riskiarviointia käyttää hyväksi myös ohjelmistokehityksen tietoturvastandardi ISO/IEC 27034. Suosittelen vilkaisemaan standardia, vaikka sitä ei käyttöönottaisikaan.

Osana riskiarviointia pyritään tunnistamaan mahdolliset uhat, koska tuntemattomia uhkia vastaan on vaikea, ellei jopa mahdotonta suojautua. Uhkamallinnuksen avulla pyritään tunnistamaan erilaisia järjestelmään vaikuttavia uhkia. Uhkamallinnusta tehdään usein työpajoissa, joissa on eri alueiden asiantuntijoita mukana, jolloin saadaan erilaisia näkemyksiä järjestelmää koskevista uhkista. Uhkamallinnustyöpajoja vetäessä olen havainnut, että mitä erilaisimmilla ajatusmaailmoilla mukana olevat henkilöt on varustettu, sitä paremmin uhkia pystytään tunnistamaan. Samalla lailla ajattelevat henkilöt tunnistavat usein samat uhat, joten tässäkin asiassa erilaisuus on rikkaus.

Uhkamallinnukseen on useita erilaisia menetelmiä. Tunnetuimpia lienee DREAD  ja STRIDE -muistisääntöjen käyttäminen. Ne ohjaavat ajatusmaailmaamme miettimään mahdollisia uhkakuvia, jotka järjestelmää voisi kohdata. Valitettavasti usein kognitiivinen vinouma ohjaa ajatuksemme miettimään tuttuja ja turvallisia asioita, emmekä pysty ajattelemaan esimerkiksi käyttäjää, joka keksii käyttää sovellusta ”väärin”.

Riskienhallinnan kannalta on tärkeää dokumentoida havaitut uhat ja niihin liittyvät riskit. Dokumentointi ei ole tärkeää dokumentaation synnyttämiseksi, vaan sitä tulisi käyttää hyväksi tiedon välittämisessä toimijoiden välillä. Riskiluetteloa olisi syytä käydä aina silloin tällöin läpi esimerkiksi kehittäjien kesken ja arvioida, onko jotain jäänyt puuttumaan. Uusia työkaluja ei riskienhallintaan tarvita, vaan esimerkiksi laajasti ohjelmistokehityksessä käytetty Jira sopii siihen mainiosti. Usein siis ohjelmistoriskienhallinta on vain tekemistä vaille valmista. Ei kun siis tekemään!