Sovelluksen erillinen tietoturvatarkastus on alkanut olla osa monen organisaation käyttöönottoprojektia millä on ollut positiivinen vaikutus organisaatioiden tietoturvallisuuden tasoon.

Yli 15 vuoden kokemuksella olen havainnut että tarkastukset usein tulevat nopealla aikataululla, tyypillisesti viikkoa tai paria ennen käyttöönottoa. Teen viikon töitä joko kotoa tai epämukavasta neukkarista. Viikon päätteeksi kirjoitan ja esittelen raportin. Useimmiten sovelluksessa on ongelmia jotka muodostavat ison riskin. Ulkopuolisena minulla on vajaa ymmärrys järjestelmän liiketoimintahyödyistä, joten on täysin mahdollista että sovellus kuitenkin otetaan käyttöön jos yrityksen johto toteaa että käyttöönoton hyödyt ovat suuremmat kuin riskit.

Monessa tarkastuksessa on jälkinäytös. Muutaman kuukauden kuluttua yrityksessä joku muistaa järjestelmän ja kysyy voinko tulla uudestaan katsomaan tilanteen. Teen muutaman päivän töitä ja katson ovatko havaitut ongelmat edelleenkin olemassa. Varsin usein ovat. Kun kysyn kehittäjiltä miksi, vastauksena usein on että raportti on hautautunut Sharepointin syövereihin eikä kukaan ole vienyt sieltä tehtäviä työlistalle. Asiakas on siis maksanut tiedosta, jolla ei kuitenkaan ole parannettu toimintaa.

Tämä tapa toimia on huono sekä asiakkaan että konsultin näkökulmasta. Voisiko asian tehdä paremmin? Voi. Viime syksynä olen istunut yhteensä kuukauden verran kahden eri ketterällä mallilla tehtävän sovelluksen tiimien osana tekemässä tietoturvatarkastuksia. Näiden kokemusten perusteella ketterällä mallilla on useita hyötyjä.

Ensinnäkin kommunikaatio on helpompaa kumpaankin suuntaan koska istun samassa tilassa tiimin kanssa. Voin helposti kysyä onko havaitsemani outo käytös normaalia vai kannattaako minun syventyä asiaan. Lisäksi tiimin jäsenet voivat käydä katsomassa lokeista, onko testini oikeasti aiheuttanut ongelmia. He voivat myös kysyä minulta johtuuko heidän havaitsemansa tilanne tietoturvatesteistä, ne kun yrittävät rikkoa sovellusta. Perinteisessä mallissa lähettäisin asiantuntijoille sähköposteja, yrittäisin soittaa heille tai etsiä heitä käsiini avokonttoriviidakosta. Helppo kommunikaatio parantaa selvästi tarkastuksen laatua ja vähentää väärien positiivisten löydösten määrää. Väärä positiivinen löydös on asia, jonka tarkastaja esittää potentiaalisena tietoturvaongelmana, mutta joka tarkemmassa tarkastelussa ei sitä olekaan. Kaikissa tarkastuksissa tulee tällaisia löydöksiä, mutta niiden määrä pitäisi minimoida.

Toiseksi, pääsen kertomaan tiimille löydöksestä välittömästi ja sille voidaan tehdä jotain heti. Ensimmäisessä projektissa kirjoitin ongelman kuvauksen heti sovittuun ongelmatietokantaan ja kerroin löydöksestä kaikille suullisesti. Tiimi pääsi heti verifioimaan sitä. Samalla he pystyivät kysymään minulta lisätietoja ja kävimme yhteistä keskustelua ongelman vakavuudesta. Toisessa isommassa projektissa tiimi käytti Kanban-taulua. Tässä projektissa jokainen löydös kirjattiin paitsi projektin Wikiin niin myös Kanban-taululle laitettavalle tehtävälapulle. Löydetyille tietoturvaongelmille perustettiin tilapäisesti oma työjono, ja joka päiväpalaverissa esittelin uudet löydökset jos niitä oli. Tiimi otti tietoturvajonosta löydöksiä korjattavakseen.

Perinteisellä mallilla olisin kirjoittanut dokumentin tarkastuksen tuloksista, tähän menee usein yksi kokonainen päivä jos löydöksiä on paljon tai niiden hyväksikäyttömenetelmien kuvaaminen on työlästä. Tämä yleensä PDF-muotoinen dokumentti annetaan asiakkaalle projektin lopussa lopputuotoksena. Koska tulos valmistuu tarkastuksen viimeisenä päivänä, korjauksiin voi olla todella vähän aikaa ennen suunniteltua käyttöönottoa. Valitettavasti dokumentin käyttökelpoisuus ei ole kovin hyvä kehittäjien näkökulmasta. Jotta siitä saataisiin hyötyä, jonkun pitää siirtää tiedot dokumentista kehittäjien omiin työvälineisiin, analysoida ja priorisoida korjaukset ja lopuksi aikatauluttaa ne. Tämä vaatii asiakkaalta kypsyyttä käsitellä normaalin kehitysprosessin ulkopuolelta tulevia muutoksia.

Välittömällä löydöksestä kertomisella mahdollistetaan ongelmien nopea korjaus. Jos ongelma on hyvin selkeä, esimerkiksi yhdestä toiminnosta puuttuva käyttöoikeustarkastus, korjaus voi olla valmis jo saman päivän aikana.

On mallilla toki haittojakin perinteiseen toimintatapaan verrattuna.

Suurin ongelma on välittömän raportoinnin aiheuttama priorisoinnin hankaloituminen ja kokonaiskuvan vajavuus. Kun raportin kirjoittaa tarkastuksen päätteeksi, voi jokaisen löydöksen vakavuutta arvioida muiden löydösten valossa. Tietyt ongelmat kun voivat olla vakavuudeltaan mitä tahansa luokkien ”tiedoksi” tai ”kriittinen tietoturvahaavoittuvuus” väliltä, riippuen ongelman sijainnista, tyypistä ja muista löydöksistä. Jos ongelmat raportoidaan heti kun ne löydetään, pitää olla huolellinen ja aina arvioida, vaikuttaako uusi havainto vanhojen havaintojen vakavuuteen. Usein vasta tarkastuksen lopuksi voidaan muodostaa käsitys järjestelmän kokonaisturvallisuudesta.

Lisäksi havainnoista ei aina pysty tiimin kanssakaan riittävän nopeasti sanomaan, onko kyseessä tietoturvaongelma vai ei, vaan asiaa pitää selvittää lisää. Tämän vuoksi Kanban-taulun tietoturvaosio jaettiin kahtia. Toiseen vietiin selvät tietoturvaongelmat, joiden korjaus oli yksinkertaista. Toiseen vietiin ongelmat, joiden olemassaolo piti varmistaa, joiden korjaus ei ollut triviaalia tai joiden priorisoinnista piti kysyä tuoteomistajalta. Tämä toimi tietoturvallisuuden työstettävänä kehitysjonona.

Hankalaa voi olla myös se, että ketterä kehitys ei pysähdy tietoturvatarkastusta varten. Tämä voi aiheuttaa päänvaivaa sekä tiimille että tarkastajalle. Tiimi kehittää, jatkuvan integraation skriptit pyörivät ja uusia versioita asentuu koko ajan. Järjestelmä voi siis muuttua alta yllättävästi. Tietoturvatarkastajalle on ongelma, jos eilen iltapäivällä tehtyä havaintoa ei enää tänään löydykään. Ja kehitystiimille voi olla ongelma, jos testijärjestelmä on tukossa kun tietoturvatestauksen automaattityökalut takovat omia testejään.

Viimeinen ongelma on ajan käytössä ja tarkastajan roolissa pysymisessä. Kun tiimin kanssa istuu samassa tilassa, tulee helposti keskusteltua löydöksistä enemmänkin.  Usein tarkastajalta myös kysytään, miten ongelma pitäisi korjata tai kelpaako jos korjaus tehdään tietyllä tavalla. Ongelma on siinä, että monissa tarkastuksen eettisissä ohjeissa todetaan että järjestelmää, jonka tekemiseen on osallistunut, ei voi tarkastaa. Kuitenkin tarkastajalla on paljon asiantuntemusta, jonka avulla voi ohjata kyselijän eri ratkaisumallien pariin tai lausua onko joku ratkaisuvaihtoehdoista ajatustasolla parempi kuin joku toinen. Tällainen keskustelu lisää asiakkaan saamaa hyötyä. Siksi tarkastajan tulee arvioida kuinka syvälle neuvomiseen voi mennä ja huolehtia ettei korjauksista keskustelu vie liikaa aikaa itse tarkastukselta. Tai tarkastukseen varataan alun perin lisäaikaa.

Ongelmista huolimatta ketterällä tietoturvatarkastuksella on yksi etu puolellaan: tarkastus on osa muutokset luonnollisesti huomioon ottavaa sovelluskehitysprosessia, ei erillinen kapuloita rattaisiin heittävä liitännäinen. Siksi toivon, että mahdollisimman moni organisaatio ottaisi tämän mallin käyttöön tai vähintään muuttaisi perinteistä malliaan ottamaan tietoturvatarkastukset paremmin osaksi kehitysprosessia. Se kannattaa, koska se säästää rahaa. Kehitysvaiheessa ongelman korjaus maksaa merkittävästi vähemmän kuin käyttöönoton jälkeen.


Lea Viljanen, LAV Security Oy