Jokainen muutos tai toimenpide sovelluksen lähdekoodiin tai palveluympäristöön voi aiheuttaa uuden haavoittuvuuden. Mikäli sovellus kehittyy kovaa tahtia ja tietoturvatestausta ei suoriteta säännöllisesti, syntyy testivelkaa.
Mitä tarkoittaa testivelka tietoturvatestauksessa?
Testivelka tarkoittaa käytännössä sitä, että kaikkia tietoturvan kannalta merkityksellisiä osia ei ole testattu kunnolla tai ollenkaan. On saatettu testata sovelluksen edellistä versiota tai testaus on suoritettu ajallisesti kauan sitten.
Sovellus kokonaisuutena on yhtä vahva, kuin sen heikoin lenkki. Toisin sanoen, hyökkääjä on tyytyväinen löytäessään yhdenkin merkittävän tai kriittisen haavoittuvuuden.
Mikäli tietoturvatestausta ei toteuteta säännöllisesti ja testivelkaa on paljon, riski ilmeisen haavoittuvuuden olemassaoloon on merkittävä.
Edelliseen versioon suoritettu tietoturvatestaus ei takaa järjestelmän tietoturvallisuutta tänään
Merkittävän lisämausteen verkkosovelluksien tietoturvaan tarjoaa jatkuvasti kehittyvä toimintaympäristö. Käytännössä tietoturvan vaatimukset ja kyberhyökkäykset kehittyvät jatkuvasti. Periaatteessa viime viikolla toimivaksi ja turvalliseksi todettu sovellus voikin olla tällä viikolla turvaton, vaikka mitään ei olisi muutettu
Malli esimerkki on HTTP request smuggling (https://en.wikipedia.org/wiki/HTTP_request_smuggling) haavoittuvuus, joka alunperin todettiin jo vuonna 2005. Haavoittuvuus konkretisoitui varsinaisesti ison yleisön tietoisuuteen viimeistään PortSwiggerin vuonna 2020 tekemän tutkimustyön pohjalta. Periaatteessa tammikuussa 2020 alkuvuodesta toimivaksi ja turvalliseksi todettu sovellus saattoikin olla kriittisen haavoittuvuuden sisältävä järjestelmä huhtikuussa 2020 ilman, että sovelluksessa itsessään mikään muuttui.
Testauksen tarve on aina olemassa
Sovelluskehitys on useimmiten prosessi, ei projekti. Sovellus saattaa syntyä projektin myötä, mutta aktiivisessa käytössä oleva sovellus vaatii ylläpitoa ja kehitystä jatkuvasti. Jos sovellus kehittyy kovaa tahtia, mutta tietoturvatestausta ei suoriteta säännöllisesti, syntyy testivelkaa.
Testauksen tarve on siis aina olemassa. Tarve ei itsestään katoa tai ratkea niin kauan, kun sovellusta käytetään. Toisaalta pitkään kumuloitunut testivelka voi aiheuttaa tietoturvaan liittyvien riskien kasvamista tai realisoitumista ja tilanteen hallintaan ottaminen vaikeutuu mitä enemmän testivelkaa syntyy.
On tärkeää luoda prosessi, jonka myötä sovellukseen suoritetaan huolto- ja kehitys-toimenpiteitä hallitusti ja säännöllisesti.
Riittääkö, että sovellus testataan kerran vai pitäisikö testausta suorittaa useammin tai jopa säännöllisesti?
Mikäli sovelluksen elinkaari on pitkä, myös kehityksen elinkaari on pitkä. Erityisesti kriittisten ja pitkän elinkaaren omaavissa sovelluksissa tietoturva on tärkeä ottaa huomioon huolto- ja kehitys prosessin aikana määrätietoisesti.
Ketterän kehityksen menetelmin suoritettavassa sovelluskehityksessä sovellus syntyy osissa. Tarkoituksena ei ole rakentaa järjestelmää kuten Iisakin Kirkkoa vaan viedä ominaisuuksia tuotantoon niin pian, kuin se on järkevästi mahdollista.
Tietoturvatestaus onkin järkevää sovittaa ketterän kehityksen rytmiin siten, että uudet ominaisuudet, muutokset ja kokonaisuus testataan mahdollisimman pian julkaisujen aikataulu huomioiden.
Jokainen muutos tai toimenpide sovelluksen lähdekoodiin tai palveluympäristöön voi aiheuttaa uuden haavoittuvuuden. Jatkuva tietoturvatestaus sovituissa sykleissä mahdollistaa muutosten ja toimenpiteiden testaamisen säännöllisesti. Tämä varmistaa sen, että tietoturva pysyy sovelluskehityksen tahdissa.
Kun turvallisuuteen suhtaudutaan ammattimaisesti, sovelluksen tietoturvasta vastaavilla tahoilla on säännöllisesti tilannekuva:
- mitkä osat sovelluksesta on testattu
- milloin ne on testattu
- kuka on testannut
- ja miten ne on testattu.
Onko teille päässyt kertymään testivelkaa?
Tutustu tietoturvatestauksen palveluihin
