CTO:mme Juho Ranta keskusteli Ohjelmisto- ja e-business RY:n webinaarissa siitä, mitä ohjelmistoyrityksiltä edellytetään, jotta se täyttää omien sekä asiakkaan sidosryhmien tietoturvatarpeet. Postaussarjan ensimmäisessä osassa kerromme asiakkaan tahtotilan ymmärtämisestä ja mitä se edellyttää toimittajalta. Myöhemmin julkaistavassa toisessa osassa keskitymme toimittajan vastuisiin tietoturvan osalta.
Asiakkaiden ja toimittajien välinen nykytilanne
Kun halutaan tuottaa asiakkaalle asiakkaan tietoturvavaatimukset täyttäviä sovelluksia, lähdetään liikkeelle asiakkaan tahtotilan ymmärtämisestä. Tietoturvan osalta tämä saattaa joskus olla haastavaa, sillä asiakkaan edustaja ei aina itse välttämättä tiedä millainen tilatun ohjelmiston tietoturvan tulisi olla, eikä asiakkaan ja toimittajan välillä useinkaan ole sovittu yksiselitteisiä ja kattavia tietoturvavaatimuksia.
Kun vaatimuksia ei ole määritelty, johtaa tämä tilanteeseen, jossa toimittaja ei tiedä, mikä on asiakkaan tahtotila tietoturvan suhteen. Asiakas puolestaan olettaa ohjelmiston toimittajan huolehtivan tietoturvasta. Tämä johtaa helposti tilanteeseen, jossa asiakas olettaa saavansa asioita, joista ei ole sovittu. Toimittaja puolestaan ei pysty asiakkaan tahtotilaan vastaamaan, koska asioista ei ole sovittu. Lopputuloksena ollaan tilanteessa, jossa kumpikaan osapuoli ei ole tyytyväinen.
Tietoturva ohjelmistokehityksessä on monitahoinen asia, jossa toimittajalla on suuri rooli, jotta asiakas saa sitä mitä todella tarvitsee. Toimittajan osalta on äärimmäisen tärkeää selvittää asiakkaan tahtotila tietoturvan suhteen. Jos asiakkaalla ei ole entuudestaan selkeää näkemystä, voi keskustelun aloittaa selvittämällä asiakkaan kanssa heidän sidosryhmiensä tietoturvatarpeet sovellukselle. Lähes jokaisella yrityksellä on ainakin seuraavat sidosryhmät, joiden tahtotilaa se joutuu kuuntelemaan:
- Liikkeen johto
- Omistajat
- Henkilöstö
- Asiakkaat
- Yhteiskunta lainsäätäjän ja yritysvastuun roolissa
Asiakkaalla tulisi olla ymmärrys, mitä edellä mainitut osapuolet edellyttävät hankittavalta sovellukselta ja tuovatko he jotain tietoturvaan vaikuttavia vaatimuksia.
Tietoturvavaatimuksista on hyvä ymmärtää se, että tietoturva ohjelmistokehityksessä ei pelkästään tarkoita mahdollisimman vähäistä haavoittuvuuksien määrää, jonka pitäisi olla lähtökohta kaikissa tilanteissa. Usein asiakkaalta tulee vaatimuksia, jotka voivat esimerkiksi vaikuttaa lokitukseen, käyttäjien tunnistamiseen sekä moniin muihin aioihin ja näiden kehitys vaatii usein lisätyötä.
Näiden asioiden kommunikoiminen olisi hyvä aloittaa mahdollisimman aikaisessa vaiheessa kuitenkin siten, että toimittaja on voinut huomioida nämä vaatimukset tarjouksessa. Vaatimuksiksi kannattaa lähtökohtaisesti kirjata asioita, jotka ovat mitattavissa ja yksiselitteisiä – näin kummallakin osapuolella on sama käsitys asioista, eivätkä mahdolliset tulkintaerot tulevaisuudessa aiheuta ongelmia.
Kilpailutilanteessa olisi hyvä pyrkiä saamaan jo tarjouspyyntöön tietoturvalta vaadittavat asiat. Jos tämä ei ole mahdollista, tulisi nämä selvittää asiakkaalta ennen tarjouksen jättämistä. Samalla on tärkeää pyrkiä varmentamaan, että samat vaatimukset on myös kommunikoitu kilpailijoille, jotta hekin joutuvat tarjouksessaan nämä huomioimaan. Muuten riskiksi muodostuu tarjoukset, joita on vaikea vertailla.
Räätälöity sovellus vs SaaS
Räätälöidyn sovelluksen ja SaaS-tuotteiden välillä on eroja, jotka vaikuttavat tietoturvaan ja sen tuomiin vastuukysymyksiin. Räätälöidyssä sovelluksessa voidaan karkeasti sanoa tilaajan olevan vastuussa tuotteesta, sillä asiakas on itse määrittänyt vaatimukset ja on itse vastuussa ylläpidosta, käytöstä sekä päivityksistä. Toimittaja on yleensä vastuussa vain takuun ajan, mutta maailma kehittyy ja ohjelmistot vaativat päivityksiä, jotta ne pysyvät turvallisina ja toimivina. Vastuu näistä siirtyy asiakkaalle itselleen, ellei toimittajan kanssa ole sovittu ylläpidosta.
SaaS-palvelussa taas toimittaja vastaa tuotteen ylläpidosta ja päivityksistä. Tietoturvan osalta toimittajalla on tarve osoittaa tuotteen tietoturvallisuus asiakkaille, koska asiakkaalla itsellään on tähän huomattavasti vähemmän mahdollisuuksia vaikuttaa. Lähtökohtaisesti SaaS-palveluissa toimittaja vastaa itse tuotteesta ja sen elinkaaresta.
On kriittistä kuitenkin muistaa, ettei SaaS-palveluiden osalta voida riskiä ulkoistaa toimittajalle, vaikka toimittaja vastaakin varsinaisesta toteutuksesta. Tiedon omistaja kantaa aina riskin omista tiedoistaan, täten myös asiakas kantaa aina vastuun omasta liiketoiminnastaan ja siihen kohdistuvista riskeistä. Tästä syystä myös SaaS-palveluiden tietoturva tulisi asiakkaan toimesta pyrkiä varmentamaan mahdollisimman hyvin.
Tietoturvan hinta
Fakta on, että tietoturva maksaa aina. Summa muodostuu riskien, eli odotusarvollisten tappioiden, suuruudesta sekä tietoturvakontrollien kustannuksesta. Riskiä voidaan pyrkiä pienentämään implementoimalla erilaisia kontrolleja, mutta tämä luonnollisesti nostaa kustannuksia. Mikäli riskejä ei aktiivisesti pyritä pienentämään, ovat kontrolleihin menevät kustannukset huomattavasti pienemmät, mutta odotusarvolliset tappiot puolestaan kasvavat. Yleensä optimipiste, eli näiden kahden tekijän summan minimi, on jonkinasteinen kompromissi kahden ääripään välissä; riskejä pyritään pienentämään mielekkäällä tavalla, mutta ei liikaa. Se, mikä on sopiva taso riippuu paljon eri tekijöistä, kuten esimerkiksi sovelluksen kriittisyydestä, siellä olevasta tiedosta ja asiakkaan riskinsietokyvystä. Tietoturva ohjelmistokehityksessä sekä sen hinta voikin siis vaihdella riippuen asiakkaan tarpeista.
Edellä mainittu asia on hyvä myös asiakkaan ymmärtää; vaikka tietoturva nostaisi projektin kustannuksia, voi se silti laskea kokonaiskustannuksia johtuen merkittävästi pienentyneistä riskeistä.
Entä jos asiakas ei osaa vaatia?
Valitettavasti jokainen toimittaja törmää tilanteisiin, jossa asiakas ei halua tai ymmärrä vaatia tietoturvaa, vaikka edellä mainittuja asioita olisi kuinka käyty läpi. Näitä tilanteita varten jokaisella organisaatiolla tulisi olla myös tietoturvan osalta ns. perustaso, joka toteutetaan aina. Tämä voi esimerkiksi tarkoittaa sitä, että sovelluskehitysprosessissa tietoturva pyritään huomioimaan siten, että suoria hyväksikäytettäviä haavoittuvuuksia syntyisi mahdollisimman vähän. Tällöin on lähtökohtaisesti huomioitu perusasiat, mutta tietoturvaan tuotavat panostukset eivät vielä nosta projektien hintaa merkittävästi.
Avaintekijänä tässä on kehittäjien SDL:n (security development lifecycle) implementoiminen sovelluskehitysprosessiin. Kyseinen prosessi varmistaa, että tietoturva huomioidaan riittävällä tasolla. Yleensä SDL:n tavoitteena on se, että sovellus olisi alusta asti julkaisukelpoinen myös tietoturvan osalta. Hyvin implementoitu SDL osaa myös ottaa huomioon asiakkaan eritystarpeet ja varmentaa sen, että asiakkaan tahtotila kommunikoidaan mahdollisimman aikaisessa vaiheessa projektitiimille.
Mitä tämä kaikki edellyttää?
Jotta päästäisin tilanteeseen, jossa toimittaja kykenee varautumaan erilaisiin tilanteisiin asiakkaan osalta tietoturvan suhteen, vaaditaan toimittajalta tiettyjen sisäisten prosessien sekä työkäytänteiden luomista.
Ensimmäiseksi on lähdettävä liikkeelle asiakkaan sidosryhmien tarpeiden ymmärtämisestä, jotka tietysti vaihtelevat riippuen asiakkaasta. Sidosryhmien tarpeiden ymmärtäminen vie pitkälle tietoturvan rakentamisessa ja näiden tarpeiden ymmärtäminen tapahtuu keskustelemalla asiakkaan kanssa. Jollei asiakas itse osaa suoraan määritellä tietoturvavaatimuksia, toimittaja voi auttaa asiakasta eteenpäin ja selvittää asiakkaalta ylempänä listattujen sidosryhmien vaatimuksia suunnitteilla olevalle sovellukselle.
Sisäisesti toimittajan on koulutettava omaa henkilöstään tietoturvallisiin toimintatapoihin ja ottaa käyttöön sovelluskehitysprosessi, joka huomioi tietoturvan (SDL). Koulutuksessa on hyvä huomioida, ettei jokaisen tarvitse olla tietoturva-asiantuntija, mutta perusasiat oman työnkuvan kannalta on hyvä ymmärtää. Esimerkiksi sovelluskehittäjien on hyvä tietää, miten tietoturva huomioidaan sovelluskehityksessä ja perusasiat haavoittuvuuksista. Mikäli projektin havaitaan olevan tietoturvakriittinen, voi kehitystiimiin tulla mukaan henkilö, joka on enemmän keskittynyt tietoturvaan ja osaa tukea muita kehittäjiä tietoturvan osalta (ns. security champion).
Ei sovi unohtaa, että näiden toimintatapojen integroimiseen kuluu aikaa ja kehitystä kannattaa tehdä vähän kerrallaan. Esimerkiksi organisaatio voi aloittaa SDL:n kehityksen pala kerrallaan ja ottaa erilaisia toiminteita vähitellen omaan sovelluskehitysprosessiinsa. Näin muutos ei ole yhdellä kertaa liian raskas, eikä syö liikaa organisaation resursseja.
Juho Ranta
Juho Ranta (CISA, CISM, CISSP, CRISC) on 2NS:n teknologiajohtaja ja yksi yrityksen perustajista. Juholla on mittava kokemus organisaatioiden tietoturvan kehittämisestä ja hänen erityisosaamiseensa kuuluvat tekninen sekä hallinnollinen tietoturva.