Näin valmistaudut tunkeutumistestaukseen

Testaajan aika on kallista, ja huonosti valmistellussa toimeksiannossa iso osa siitä kuluu odottamiseen: tunnuksia ei ole, palomuuriin ei ole tehty avausta, yhteyshenkilöä ei tavoita. Nämä ovat valmistautumisen kysymyksiä, eivät testauksen – ja ne ratkaistaan ennen sopimuksen allekirjoittamista.

Määritä tavoite

Vastaa ensin siihen, mitä haluat tietää. Pitääkö täyttää valvojan vaatimus? Testata uusi sovellus ennen julkaisua? Selvittää, kuinka pitkälle hyökkääjä pääsisi tavallisen työntekijän tunnuksilla? Vai tarkistaa, huomaako valvontatiimi ylipäätään mitään?

Nämä tavoitteet vaativat eri testin. Vaatimustenmukaisuuteen tähtäävän testin laajuus ja menetelmä valitaan sovellettavien vaatimusten perusteella; yksittäinen testi ei yksin todista vaatimustenmukaisuutta. Havaitsemiskykyä voi harjoitella avoimesti tai arvioida peitetyllä testillä, josta valvontatiimi ei tiedä mutta jonka johto on hyväksynyt. Jos tavoitteesta ei sovita etukäteen, lopputuloksena on raportti, joka on muodollisesti oikein mutta ei vastaa siihen kysymykseen, joka mietitytti.

Komission täytäntöönpanoasetuksen (EU) 2024/2690 liitteen 6.5.2 kohta kirjaa tämän myös velvoitteeksi: turvallisuustestien tarve, laajuus, tiheys ja tyyppi määritetään riskinarvioinnin perusteella – ei mutu-tuntumalla eikä viime vuoden laskun mukaan. Velvoite sitoo vain asetuksessa luetellut digitaalisen infrastruktuurin ja digipalvelujen tarjoajat, ei kaikkia NIS2-toimijoita, mutta sääntö on hyvä lähtökohta kaikille.

Rajaa laajuus

Laajuus määrää, mikä kuuluu testiin ja millä ehdoilla. NCSC korostaa, että rajaus on yhteistyötä: riskin omistaja, tekninen väki ja testaustiimi määrittävät yhdessä tekniset rajat, testin tyypin, aikataulun ja tarvittavat resurssit, ja tuloksena on dokumentoitu toimintasuunnitelma.

• Listaa konkreettiset järjestelmät, sovellukset, verkkotunnukset ja IP-alueet.
• Merkitse, mikä on liiketoiminnalle kriittisintä – missä löydös sattuu pahiten.
• Sovi, mitä tekniikoita saa käyttää ja mitä ehdottomasti vältetään.
• Varmista luvat: testataan vain omia tai kirjallisesti valtuutettuja järjestelmiä.
• Tarkista kohteiden omistajuus – pilvi- ja konesalipalveluilla voi olla omat testausehtonsa.

Valmistele laajuuden rinnalla myös se, minkä testaajalle luovutat: tunnukset jokaista käyttäjäroolia kohden, pääsyn testiympäristöön jos sellaista käytetään, rajapintadokumentaation ja listan järjestelmistä, jotka ovat herkkiä tai pitkään päivittämättä. Mitä vähemmän testaaja odottaa pääsyjä, sitä enemmän aikaa jää itse testaukseen.

Mikä määrää laajuuden, keston ja hinnan

Hinta ei ole kohteen listahinta, vaan se johdetaan työpäivien määrästä. Siksi tarjous ei ala luvusta, vaan muutamasta kysymyksestä, joiden vastaukset sen luvun muodostavat.

Testin laajuuteen ja kestoon vaikuttavat tekijät

Tekijä	Kysymys, johon vastaat	Miten vaikuttaa laajuuteen
Kohteiden määrä	Montako osoitetta, verkkotunnusta ja sovellusta testataan?	Kasvattaa suoraan tarvittavien työpäivien määrää
Lähestymistapa	Musta, harmaa vai valkoinen laatikko?	Musta vie aikaa kartoitukseen, valkoinen kattavuuteen
Toiminnallisuuden syvyys	Montako käyttäjäroolia ja integraatiota sovelluksessa on?	Jokainen rooli kertautuu testattavissa skenaarioissa
Ympäristö	Testataanko tuotantoa vai erillistä kopiota?	Tuotanto vaatii varovaisemman tahdin ja enemmän sopimista
Peitteisyys	Tietääkö valvontatiimi testistä?	Peitetty testaus pakottaa hitaampaan työskentelyyn
Jatkotoimet	Tarvitaanko uusintatestaus ja tulosten läpikäynti?	Suunnitellaan ja hinnoitellaan erikseen varsinaisesta testistä

Tarjousten hintaerot selittyvät useimmiten työpäivien määrällä eivätkä päivähinnalla. Siksi tarjouksia vertailtaessa kannattaa pyytää erittely suunnitelluista työpäivistä ja siitä laajuudesta, johon ne on varattu – muuten vertaillaan eri asioita, ja halvin tarjous kattaa yksinkertaisesti vähemmän.

Valitse lähestymistapa

Valitse lähestymistapa tavoitteen ja mallinnetun hyökkääjän tietojen mukaan. Musta laatikko arvioi pääsyreittejä ilman annettua sisäistä tietoa. Harmaa laatikko käyttäjätunnuksineen auttaa pääsynhallinnan tarkistamisessa. Valkoinen laatikko koodin ja dokumentaation kanssa mahdollistaa sisäisten ratkaisujen syvemmän tarkastelun. Kattavuus riippuu myös ajasta ja osaamisesta. Vaihtoehdot on vertailtu perusoppaassa ja rinnakkain etusivulla.

Päätä erikseen, tietääkö oma valvontatiimi testistä. NIST erottaa avoimen testauksen, jossa IT-väki on mukana ja oppii samalla, ja peitetyn testauksen, joka tehdään ilman heidän tietoaan mutta ylimmän johdon nimenomaisella luvalla. Peitetty testaus näyttää havaitsemiskyvyn, mutta maksaa enemmän ja kestää kauemmin.

Sovi pelisäännöt kirjallisesti

NISTin pelisääntömalliin kirjataan testin tarkoitus ja testattava organisaatio, laajuuden rajat, oletukset ja rajoitukset sekä testaukseen liittyvät riskit ja niiden lieventämiskeinot. Logistiikkaosassa luetellaan kaikki yhteyshenkilöt poikkeamanhallinta mukaan lukien sekä tarkka aikataulu kellonaikoineen.

• Mitä testataan ja mikä jää selvästi laajuuden ulkopuolelle.
• Mitkä tekniikat ovat sallittuja ja mitkä kiellettyjä.
• Milloin testataan – päivällä, iltaisin vai viikonloppuisin.
• Miten kriittisestä löydöksestä ilmoitetaan heti, odottamatta raporttia.
• Milloin testaajan on keskeytettävä ja keneen otettava yhteyttä.
• Miten testin aikana kerätty aineisto säilytetään ja hävitetään.

Sovi etukäteen myös siitä, mitä tapahtuu, jos testaaja löytää aidon tietomurron. Testaajat törmäävät toisinaan siihen, että järjestelmässä on jo joku muu. Silloin testi keskeytetään ja työ siirtyy poikkeamanhallinnalle – tämä menettely pitää kuvata ennen aloitusta, ei keksiä samana päivänä. Suomessa menettelyllä on myös lakisääteinen jatko: jos organisaatio kuuluu kyberturvallisuuslain soveltamisalaan ja poikkeama on merkittävä, ennakkoilmoitus Traficomin Kyberturvallisuuskeskukselle on tehtävä 24 tunnin kuluessa. Vuorokausi kuluu nopeasti sen selvittämiseen, oliko järjestelmässä testaaja vai joku muu – siksi ilmoitusvastuu ja sen aikaraja kannattaa kirjata pelisääntöihin siinä missä testaajan yhteystiedotkin.

Miten testaaja valitaan

Riippumattomuus ja pätevyys painavat enemmän kuin hinta. TLPT-testaajia koskevan DORA-asetuksen 27 artiklan 1 kohdan kriteereitä voi hyödyntää hankintakysymyksinä myös muualla. Ne eivät silti ole kaikkien testien pakollinen vaatimuslista: erityisen korkea soveltuvuus ja maine, tarvittavat tekniset ja organisatoriset valmiudet, näyttöä asiantuntemuksesta uhkatiedustelussa ja tunkeutumistestauksessa, jäsenvaltion akkreditointielimen sertifiointi tai viralliset käytännesäännöt, riippumattoman tahon varmistus riskienhallinnasta sekä kattava ammatillinen vastuuvakuutus.

Saman asetuksen 24 artiklan 4 kohta lisää periaatteen, joka pätee laajemminkin: testin suorittajan on oltava riippumaton, olipa hän sisäinen tai ulkoinen, ja sisäistä testaajaa käytettäessä eturistiriidat on estettävä testin suunnittelu- ja toteutusvaiheissa. Myös asianmukaisesti eriytetty sisäinen tiimi voi tehdä riippumattoman arvioinnin; eturistiriidat on hallittava.

Käytännön tarkistus ennen sopimusta: pyydä anonymisoitu malliraportti. Siitä näkee enemmän kuin mistään tarjouksesta – onko löydöksillä todisteet, ovatko suositukset konkreettisia, onko johdon tiivistelmää ja onko teksti ylipäätään kirjoitettu luettavaksi eikä vain auditointikansioon liitettäväksi.

Valmistele organisaatio

• Nimeä yhteyshenkilö, joka on tavoitettavissa koko testauksen ajan.
• Ilmoita konesali- tai pilvipalvelun tarjoajalle, jos sen ehdot sitä edellyttävät.
• Varmista, että varmuuskopiot toimivat ja että palautuksen osaa useampi kuin yksi ihminen.
• Päätä, kerrotaanko valvontatiimille, ja kirjaa päätös ylös.
• Älä lykkää kiireellisiä tietoturvapäivityksiä testin vuoksi. Kirjaa muutokset ja testaa arkikäytössä oleva kokoonpano.

Valmistautumisen tavoitteena on luotettava arvio arkikäytössä olevasta ympäristöstä. Vältä vain testin ajaksi tehtäviä muutoksia, jotka myöhemmin perutaan. Tee pysyvät tietoturvaparannukset odottamatta testiä ja kerro testaajille, mikä muuttui.

Hyödynnä tulokset

1. Käy raportti läpi yhdessä testaajan kanssa ja varmista, että jokainen löydös on ymmärretty.
2. Priorisoi vakavuuden ja kohdejärjestelmän merkityksen mukaan, ei pelkän pistemäärän perusteella.
3. Korjaa kriittiset ja korkean riskin löydökset ensin, vastuuhenkilöineen ja määräaikoineen.
4. Tee uusintatestaus, jossa tarkistetaan sovitut korjaukset ja niihin liittyvät toiminnot. Se ei takaa kaikkien muiden heikkouksien löytymistä.
5. Etsi juurisyy: jos sama virhe toistuu useassa järjestelmässä, korjattava on prosessi eikä yksittäinen järjestelmä.

Raportti kannattaa lukea myös seuraavan kierroksen syötteenä. Jos sama löydös palaa toistamiseen, vika ei ole testaajassa, vaan korjausprosessissa; jos löydökset keskittyvät yhteen järjestelmään, selvitä juurisyy ja arvioi, voiko sama puute koskea muitakin järjestelmiä.

Miksi hyvä raportti ei yllätä

NCSC muotoilee ihanteen, joka kuulostaa yllättävältä: hyvin valmistautuneen organisaation pitäisi suunnilleen tietää, mitä testaajat löytävät, jo ennen kuin he löytävät sen. Jos raportti yllättää, ongelma ei yleensä ole testissä, vaan haavoittuvuuksien hallinnassa.

Sama ohje muistuttaa, ettei suunniteltu testi lopeta tavanomaista tietoturvatestausta – sen arvioiminen, toimivatko määritellyt kontrollit, ei ole arvokkain tapa käyttää kallista testaajan aikaa. Taustalla oleva uhkatilanne käy ilmi ENISAn vuosikatsauksesta: vuoden 2025 raportissa analysoitiin 4 875 poikkeamaa ajalta 1.7.2024–30.6.2025. Kotimaassa kyberturvallisuuslain 30 § antaa vielä valvovalle viranomaiselle oikeuden velvoittaa toimija teettämään riskienhallintaan kohdistuva turvallisuusauditointi – testaus kannattaa siis hoitaa kuntoon ennen kuin siihen velvoitetaan.