Asiakkaan ICT-ympäristön tai tietyn järjestelmän tietoturvallisuuden tason arviointiin käytetään useita erilaisia menetelmiä. Ympäristön hyökkäyspinta-alaa kartoitetaan teknisin työkaluin kuten haavoittuvuusskannerilla hyödyntäen avoimiin tietolähteisiin perustuvia tekniikoita, sekä asiakkaan vastuuhenkilöitä haastattelemalla​. Teknisiä tietoturvakontrolleja arvioidaan alan parhaita käytäntöjä ja soveltuvia viitekehyksiä vasten​, jotta saadaan kuva niiden riittävyydestä ja kattavuudesta tarkasteltavan järjestelmän käyttötarkoitukseen nähden. Joissakin tapauksissa asiakas haluaa mennä vielä pidemmälle ja pyrkiä koeponnistamaan tietoturvan tason murtotestauksella eli penetraatiotestauksella. Tällaisessa testauksessa "valkohattuhakkeri" pyrkii hankkimaan pääsyn kohdejärjestelmään erilaisia asiakkaan kanssa yhteisesti sovittuja keinoja hyväksi käyttäen. Tarkoituksena on osoittaa käytännössä mahdolliset puutteet kohteen suojauksissa. Tässä jutussa kuvataan tiiviisti millaisia tehtäviä järjestelmän penetraatiotestaukseen voi tyypillisesti sisältyä

Tarkoitukseen sopiva testaustapa sovitaan yhdessä asiakkaan kanssa

Testaus voidaan suorittaa erilaisia malleja käyttäen, esimerkiksi Black Box tai White Box -mallilla. Asiakkaan kanssa sovitaan tarkoitukseen sopivin testaustapa. Black Box -testauksessa lähtötilanne vaatii ”hyökkääjältä” enemmän aikaa ja työpanosta, koska käytettävissä ei ole kohdejärjestelmästä sisäpiirin tietoa, kuten dokumentaatiota tai lähdekoodia.

White Box -testauksessa jo lähtötilanteessa ”hyökkääjällä” on enemmän tietoa kohteesta sekä mahdollisesti pääsyoikeuksia lähdekoodiin tai käyttöoikeuksia itse järjestelmään. Tämän ansiosta White Box -penetraatiotestauksessa prosessin läpivientiä on mahdollista nopeuttaa ja tehostaa. Testaaja voi esimerkiksi hyödyntää järjestelmän lähdekoodia mahdollisten haavoittuvuuksien nopeampaan paikantamiseen tai ”kaapattuja” peruskäyttäjän käyttöoikeuksia järjestelmään kirjautumiseen. Näin ollen jo suunnittelussa ja työmäärän arvioinnissa voidaan Black Box -testausta paremmin ottaa huomioon testattavan kokonaisuuden arkkitehtuuri ja käytetyt teknologiat – sekä tämän perusteella valita testaukseen tarvittava erityisasiantuntemus. Edellä mainitut seikat tekevätkin White box -testauksesta kustannustehokkaamman menetelmän tulosten aikaansaamiseksi. Järjestelmän tuntemus parantaa myös mahdollisuuksia raportoinnin kohdentamiseen eri osajärjestelmiin.

Miten penetraatiotestaus hoituu käytännössä?

1. Aloitus

Testattavan kokonaisuuden laajuus ja testaustapa vaikuttavat työmäärään ja testauksen vaatimaan kalenteriaikaan. Netumin suorittamat penetraatiotestaukset oletusarvoisesti sisältävät aloituspalaverin, jossa käydään läpi toimeksiannon kannalta oleellisia asioita; esimerkiksi tarkastuksen kohde tai kohteet, käytettävät tekniikat, asiakkaan ja Netumin yhteyshenkilöt, kommunikaatiokanavat ja yksityiskohdat tiedonkäsittelystä sekä materiaalien säilytyksestä. Palaverissa sovitaan myös testauksen käytännön asioita, kuten tarvittavien pääsyjen sekä oikeuksien järjestämisestä. Tämän lisäksi sovitaan, milloin toimeksiannon suoritusvaihe aloitetaan sekä varmistetaan tarvittavien sidosryhmien (esimerkiksi palvelimen ylläpitäjien) olevan tietoisia testauksesta.  

 2. Toteutus

Toteutus voi sisältää esimerkiksi haavoittuvuusskannausta tai lähdekoodin analysointia (White box). Penetraatiotestaus sisältää aina merkittävän määrän asiantuntijan manuaalista työtä, jolla kokenut ”valkohattuhakkeri” kartoittaa mahdollisia eri etenemisreittejä kohdejärjestelmään. Etenemisessä pyritään hyödyntämään havaittuja haavoittuvuuksia, mutta testausmenetelmät voivat sisältää myös ei-teknisiä lähestymistapoja, kuten käyttäjätietojen tai salasanojen kalastelua ns. ”social engineering” menetelmiä käyttäen. White box -mallin testauksessa pystytään tarjoamaan yksityiskohtainen kuvaus haavoittuvuuden hyväksi käyttämisestä (proof-of-concept), haavoittuvuuden aiheuttamista mahdollisista vaikutuksista, kriittisyysarviosta sekä myös korjausehdotuksesta jopa lähdekooditasolle asti. Suosituksiin liitetään ohjeistuksia haavoittuvuuksien korjaamiseen, viitaten esimerkiksi OWASP-ohjeistuksiin (Open Web Application Security Project).

3. Lopputulos ja testauksen hyöty 

Lopputuloksena asiakas saa yksityiskohtaisen raportin, jossa on selkeästi kuvattu johdon yhteenveto, yksityiskohtaiset kuvaukset toimeksiannon taustasta, rajauksesta sekä suorittamisesta. Raportissa on kaikki havainnot yksityiskohtaisesti kuvattuna (sisältäen havainnon todentamisen), arvioidut vaikutukset, arvio havainnon kriittisyydestä sekä selkeästi kuvatut korjausehdotukset.

Raportti käydään yhdessä asiakkaan kanssa keskustellen läpi, mikä mahdollistaa asiakkaalle lisätietojen kysymisen, liittyvätpä ne sitten raporttiin, havaintoihin tai korjausehdotuksiin. Varsinaisten haavoittuvuuksia koskevien korjausehdotuksien lisäksi asiakkaalle voidaan ehdottaa myös muita kohdearkkitehtuuriin liittyviä tietoturvan tasoa kohentavia toimenpiteitä. Esimerkkinä tietoturvallisten toimintamallien käyttöönotto tai pidemmän aikavälin kehitysehdotukset, joiden arvioidaan parantavan tuotteen tietoturvaa ja ylläpidettävyyttä. Tällaisia kehitysehdotuksia voivat olla muun muassa staattiseen koodianalyysiin soveltuvan työkalun käyttöönotto osaksi DevOps-prosessia sekä koulutusten järjestäminen tietoturvalliseen sovelluskehitykseen liittyen.