Testauksen toimitusmallit

Tiivistetysti voidaan todeta, että projektityyppinen testaus sopii parhaiten "valmiiden" järjestelmien arviointiin – eli sellaisten, joihin ei olla suunniteltu uusia ominaisuuksia toteutettavaksi tai jotka ovat muuten suojatussa ympäristössä kuten sisäverkossa.

Riippumatta toimitusmallista ensimmäinen askel on aina testattavan järjestelmän lähtötietojen määrittely:

• Mikä kohde on kyseessä?
• Mihin sitä käytetään ja ketkä ovat sen käyttäjiä?
• Mihin muihin järjestelmiin se on kytketty?
• Minkälaista tietoa se käsittelee?
• Näkyykö se Internetiin?

Projektityyppinen testaus

Projektipohjainen tietoturvatestaus on nopeassa aikataulussa toteutettava hanke, jossa kohdejärjestelmästä etsitään haavoittuvuuksia, arvioidaan niiden liiketoiminnalliset ja tekniset vaikutukset sekä laaditaan korjaussuositukset. Löydökset dokumentoidaan viralliseen raporttiin, joka esitellään tilaajalle.

Keskimääräinen projektin kesto riippuu kohteen laajuudesta ja vaihtelee yleensä kahdesta kolmeen viikkoon. Pienissä kohteissa testaus voi valmistua viikossa, kun taas suuremmissa projekteissa kesto voi ylittää kuukauden.

Millaisiin tapauksiin projektityyppinen testaus sopii?

Projektityyppinen testaus on tehokas ratkaisu kertaluonteisiin tarpeisiin, kuten:

• Sertifioinnit ja auditoinnit (esim. PCI DSS, ISO 27001)
• Yrityskaupat ja due diligence -prosessit
• Vuositarkastukset liiketoimintakriittisille järjestelmille, joihin ei kehitetä aktiivisesti uusia ominaisuuksia
• Järjestelmät, joissa muutokset rajoittuvat toimintaympäristöön tai kolmannen osapuolen komponentteihin

Yksi projektityyppisen testauksen etu on potentiaalisesti alhaisemmat aloituskustannukset verrattuna jatkuvaan testaukseen, mutta tämä riippuu tapauskohtaisesti projektin vaatimuksista.

Projektityyppisen testauksen heikkoudet

1. Pistemäisyys – Testaus tehdään tietyllä hetkellä, mutta siihen ei kuulu korjausten varmentaminen myöhemmin. Jos korjauksia ei ehditä toteuttaa heti, tilaajalla ei ole varmuutta siitä, onko haavoittuvuudet korjattu oikein ilman uutta testauskierrosta.
2. Soveltumattomuus ketterään kehitykseen – Agile-menetelmillä kehitettävät sovellukset muuttuvat jatkuvasti, jopa päivittäin. On vaikea löytää sellaista ajankohtaa, jossa yksittäinen testausprojekti kattaisi kaikki merkittävät riskit. Käytännössä testaus ajoitetaan usein suurten julkaisujen yhteyteen (major release), mutta sovellus voi muuttua huomattavasti jo pian tämän jälkeen.
3. Budjetointi ja kilpailuttaminen – Jos järjestelmää testataan vuosittain ja palveluntarjoaja kilpailutetaan joka kerta erikseen, prosessi voi olla raskas ja kallis. Kilpailutukseen sisältyy tarjousten pyytäminen, järjestelmän esittely uusille toimittajille ja tarjousten vertailu, mikä lisää hallinnollisia kustannuksia.
4. Testauksen jatkuvuuden puute – Jos järjestelmää testaa vuosittain eri tiimi, testaajat eivät pääse syventymään kohteeseen. Jokainen projekti alkaa "nollapisteestä", jolloin testaus ei paljasta ongelmia pintaa syvemmältä.

Jatkuva testauspalvelu

Jatkuva testauspalvelu eroaa projektityyppisestä testauksesta säännöllisellä ja toistuvalla toteutuksella. Tämä mahdollistaa paremman turvallisuuden hallinnan, koska järjestelmää arvioidaan jatkuvasti uusien ominaisuuksien ja muuttuvien uhkakuvien näkökulmasta.

Jatkuvassa palvelussa Kohdejärjestelmä testataan säännöllisin väliajoin lyhyissä testisykleissä (esim. kuukausittain tai kvartaaleittain).

Testisyklissä testataan:

• Uudet ja muuttuneet ominaisuudet
• Aiemmin havaittujen haavoittuvuuksien korjaukset
• Sovellukset osat joiden edellisestä testauksesta on kulunut pitkä aika

Ensimmäinen testauskierros on tyypillisesti laajempi ja se vastaa kattavuudeltaan projektimuotoista testausta.

Millaisiin tapauksiin jatkuva testauspalvelu sopii?

Jatkuva testauspalvelu soveltuu ennen kaikkea nopeasti kehittyville järjestelmille, kuten:

• Mobiili- ja verkkosovellukset, joita kehitetään ketterillä menetelmillä (Agile, SAFe)
• Pilvipohjaiset järjestelmät, jotka ovat jatkuvan muutospaineen alaisena
• Kaikki järjestelmät, joissa julkaistaan uusia ominaisuuksia säännöllisesti ja käyttö tapahtuu Internetin yli

Jatkuvan testauksen avulla tietoturvariski pienenee verrattuna vuosittaiseen testaukseen, koska ongelmat havaitaan ja korjataan nopeammin. Lisäksi se tuo esiin systeemisiä tietoturvaongelmia, jos samankaltaisia haavoittuvuuksia löytyy toistuvasti. Tämä auttaa parantamaan tietoturvan huomiointia kehitysprosessissa.

Toinen etu on testauksen jatkuvuus: koska sama tiimi testaa järjestelmää säännöllisesti, he voivat keskittyä syvemmälle meneviin testitapauksiin, eivätkä aloita jokaisella kierroksella alusta.

Jatkuvan testauspalvelun heikkoudet

1. Ei aina kustannustehokas – Jos järjestelmään tehdään vain vähäisiä muutoksia, jatkuva testaus voi tuoda vain vähän lisäarvoa verrattuna säännöllisiin projektitesteihin.
2. Vaatii tilaajalta sitoutumista – Jos löydetyt haavoittuvuudet eivät johda korjaustoimenpiteisiin, testauksesta ei saada täyttä hyötyä. Raportit voivat sisältää samoja havaintoja testisyklistä toiseen, jos kehitystiimi ei aktiivisesti käsittele tietoturvaan liittyviä puutteita.
3. Organisaation täytyy haluta parantaa tietoturvan johtamista – Jatkuva testaus toimii parhaiten yrityksissä, joissa tietoturva nähdään jatkuvana kehitysprosessina ja osaamista halutaan parantaa pitkällä aikavälillä.

Vastaukset näihin kysymyksiin auttavat ymmärtämään testauksen tarvetta ja luonnetta.

Why not both?

Entä voisiko nämä kaksi toimitusmallia yhdistää? Kyllä vain! Järjestelmien elinkaaret ja tietoturvatarpeet vaihtelevat, joten hybridimalli voi olla toimivin ratkaisu. Esimerkiksi:

• Projektityyppinen testaus ennen julkaisua, jonka jälkeen jatkuva testauspalvelu kehityksen aikana.
• Vuosittainen auditointi projektimallilla, mutta kriittisten komponenttien jatkuva testaus.
• Jatkuva testaus nopeasyklisille järjestelmille, mutta kertaluonteinen testaus ylläpitovaiheessa oleville järjestelmille.

Yhteenveto

Tietoturvatestauksen toimitusmallin valinta riippuu järjestelmän elinkaaresta, kehitysmallista ja organisaation tarpeista. Projektityyppinen testaus ja jatkuva testauspalvelu palvelevat eri käyttötarkoituksia, ja niiden hyödyt sekä rajoitteet on syytä ymmärtää ennen päätöksentekoa.

Milloin valita projektityyppinen testaus?

Projektimuotoinen testaus on tehokas ratkaisu, kun:

• Testauksen tarve on kertaluonteinen – esimerkiksi sertifiointia, auditointia tai yrityskauppaa varten.
• Järjestelmä on ylläpitovaiheessa, eikä siihen kohdistu jatkuvaa kehitystä.
• Organisaatio haluaa minimoida aloituskustannukset ja ei tarvitse jatkuvaa testausprosessia.
• Testaus halutaan ajoittaa suurten muutosten yhteyteen, kuten uuden version käyttöönottoon.

Rajoitteet:

• Pistokoemainen testaus ei tuota ajantasaita tietoturvan tilannekuvaa.
• Haavoittuvuuksien korjausten testaus vaatii erillisen projektin.
• Jokainen testauskierros voi alkaa "nollasta", jos toimittaja vaihtuu vuosittain.

Milloin valita jatkuva testauspalvelu?

Jatkuva testauspalvelu on suositeltava vaihtoehto, kun:

• Sovellus kehittyy aktiivisesti – esimerkiksi agile-kehitysmallin mukaisesti.
• Tietoturvauhkien ja järjestelmän muutosten seuranta on tärkeää.
• Organisaatio haluaa jatkuvaa näkyvyyttä sovelluksen tietoturvaan ja varmistaa haavoittuvuuksien korjaamisen.
• Testausta halutaan optimoida ajan myötä, jolloin sama testitiimi syventyy sovelluksen turvallisuuteen yhä tarkemmin.

Rajoitteet:

• Vaatii organisaatiolta sitoutumista ja valmiutta reagoida havaintoihin.
• Ei ole aina kustannustehokas, jos järjestelmään ei tehdä merkittäviä muutoksia.
• Ilman selkeitä korjausprosesseja testauksen hyödyt voivat jäädä hyödyntämättä.

Lopullinen päätös: mikä sopii teille?

Valinta riippuu seuraavista kysymyksistä:

1. Kuinka usein järjestelmää kehitetään?
   Jos jatkuvasti, valitse jatkuva testaus.
2. Kuinka tärkeää on varmistaa haavoittuvuuksien korjaaminen?
   Jos kriittistä, jatkuva testaus on paras ratkaisu.
3. Onko kyseessä kertaluontoinen tarve vai pitkäaikainen strategia?
   Kertaluontoisissa tapauksissa projektimalli voi riittää.
4. Minkälainen budjetti testaukselle on varattu?
   Projektimalli on lähtökohtaisesti edullisempi, mutta voi sisältää piilokuluja. Pitkällä aikavälillä jatkuva testaus tuo usein parempaa vastinetta rahalle.