Mikä penetraatiotesti on ja milloin yritys tarvitsee sen

Skannaus, tietoturva-auditointi ja penetraatiotesti ovat kolme eri työtä kolmella eri hinnalla. Mikä niistä vastaa kysymykseesi, ja mitä Suomen säädökset tosiasiassa edellyttävät.

Pyydät tarjousta verkkosivuston tietoturvasta ja saat kolme, jotka eroavat toisistaan kymmenkertaisesti, ja yhdessä lukee ”tietoturvaskannaus”, toisessa ”tietoturva-auditointi”, kolmannessa ”penetraatiotesti”, mutta kaikissa kolmessa on sama sana ”tietoturva”, joka ei kerro mitään siitä, mikä niissä oikeasti eroaa. Ne eivät ole yksi työ kolmessa tasossa eivätkä kolme hintaa samasta työstä, vaan kolme eri työtä, jotka vastaavat kolmeen eri kysymykseen, joten ensimmäinen askel ei ole hintojen vertailu vaan sen ymmärtäminen, mihin näistä kolmesta kysymyksestä oikeastaan haluat vastauksen.

Tämä artikkeli vastaa kahteen: mikä penetraatiotesti on ja tarvitseeko juuri sinun yrityksesi sen. Jälkimmäinen kysymys on tärkeämpi, koska valtaosalle suomalaisista pienistä ja keskisuurista yrityksistä mikään säädös ei nimeä penetraatiotestausta velvollisuudeksi, ja tarjous, joka vaikenee siitä, myy sinulle oikean palvelun väärällä hetkellä.

Kirjoitamme tämän myydessämme tietoturva-auditointia, eikä siinä ole ristiriitaa, koska auditointi, jossa on tilaa manuaaliselle tarkastukselle, ja penetraatiotesti, jota säädös edellyttää, eivät ole sama työ, mutta yritys, joka ostaa jälkimmäisen silloin kun sen piti ostaa ensimmäinen, maksaa enemmän ja oppii vähemmän.

Kolme työtä, joita myydään samankaltaisilla nimillä

Alan terminologia on tässä sotkuista, mutta sen alla on selvä raja, jonka standardointielin nimeää parhaiten: NIST SP 800-115 määrittelee penetraatiotestauksen tietoturvatestaukseksi, jossa arvioijat jäljittelevät todellisia hyökkäyksiä löytääkseen teitä järjestelmän suojauksen ohi, ja toteaa, että se etsii haavoittuvuuksien yhdistelmiä, ei yksittäisiä löydöksiä. Sama julkaisu kuvaa haavoittuvuusskannausta menetelmäksi, jolla tunnistetaan resurssit ja niitä vastaavat tunnetut haavoittuvuudet.

Käytännössä se tarkoittaa neljää eri työtä, jotka kannattaa nimetä erikseen. Haavoittuvuusskannaus on automaattinen, ja siinä työkalu vertaa järjestelmääsi tunnettujen haavoittuvuuksien tietokantaan ja palauttaa listan. Skannauksen tulosten validointi ja priorisointi on sama lista, jonka ihminen on tarkistanut ja järjestänyt, yleensä hyödyntämättä yhtäkään löydetyistä haavoittuvuuksista. Penetraatiotestaus on ihmisen johtamaa työtä, jossa löydetyt heikkoudet hyödynnetään ja ketjutetaan, jotta selviäisi, kuinka pitkälle hyökkääjä todella pääsee. Vaatimustenmukaisuuden arviointi vastaa aivan toiseen kysymykseen: täyttääkö järjestelmä nimetyn standardin tai normin.

Rajan kolmen ensimmäisen välillä piirtää terävimmin maksukorttistandardi, joka tekee sen ei määritelmällä vaan tavoitteella: PCI-tietoturvastandardineuvoston ohjeet erottavat penetraatiotestauksen skannauksesta päämäärän mukaan: skannaus tunnistaa, järjestää ja raportoi haavoittuvuudet; testi etsii tapoja hyödyntää niitä järjestelmän suojauksen kiertämiseksi. Sama neuvosto lisää standardissaan molemmat laidat: skannaus itsessään ei ole penetraatiotesti, eikä testi, joka vain yrittää hyödyntää skannerin löydöksiä, ole sekään riittävä.

Siksi kysymys ”tarvitsetko penetraatiotestin” ei ole kysymys budjetista vaan siitä, mihin haluat vastauksen: onko järjestelmässäsi tunnettuja heikkouksia, vai voiko joku niillä todella tehdä jotakin.

Mihin kukin niistä vastaa ja mitä se ei kerro

Skannaus vastaa nopeasti ja halvalla, ja sen heikko kohta on konteksti, koska työkalu ei tiedä, mikä sadasta merkitystä rivistä on maksulomakkeessasi ja mikä testiympäristössä, johon kukaan ei yllä internetistä, eikä se tiedä myöskään sitä, että kaksi erikseen harmitonta virhettä yhdessä antaa pääsyn tietokantaan — siksi lista on työn alku, ei työn tulos.

Penetraatiotesti vastaa hitaammin ja kalliimmin, ja sen arvo on juuri ketjussa, koska testaaja ei etsi vastausta kysymykseen ”onko tässä haavoittuvuus” vaan kysymykseen ”mitä tällä voin tehdä” — pääseekö julkisesta lomakkeesta ylläpitäjän oikeuksiin, näkeekö yhden asiakkaan tililtä toisen asiakkaan tiedot, yltääkö testiympäristöstä tuotantotietokantaan. Vastaus tähän kysymykseen on se, jonka johtaja ymmärtää ilman käännöstä.

Vaatimustenmukaisuuden arviointi ei tee kumpaakaan, koska se tarkistaa, täyttääkö järjestelmä normin, ja sen tulos on tuomio vaatimustenmukaisuudesta, ei lista teknisistä heikkouksista; juuri siksi yritys voi selvitä vaatimustenmukaisuuden arvioinnista ja tulla murretuksi samalla viikolla, eikä siinä ole mitään ristiriitaa, koska kaksi asiakirjaa vastaa kahteen eri kysymykseen.

Yksikään näistä töistä ei korvaa muita eikä yksikään niistä ole ”parempi” kuin toiset, joten ainoa mielekäs kysymys on se, mikä niistä juuri nyt vastaa siihen, mikä sinun on todella tiedettävä.

Nimien sekaannus ei ole vain suomalainen ongelma, ja sen näkee vertaamalla markkinoita: Suomessa, Ruotsissa ja Norjassa markkina myy kahta työtä — skannausta ja penetraatiotestiä — eikä välimuodolla ole nimeä; sitä pidetään skannauksen tuloksena, ei erillisenä palveluna. Saksassa on päinvastoin, koska siellä yksi sana usein kattaa kaikki kolme työtä, itse testi mukaan lukien, ja juuri siksi tarjouksia vertailtaessa nimi on heikoin mahdollinen opaste, mutta ainoa varma kysymys jää siihen, hyödynnetäänkö löydetyt haavoittuvuudet.

Edellyttääkö laki sitä juuri sinulta

Tässä kannattaa olla täsmällinen, koska juuri tässä tarjoukset liioittelevat useimmin: Suomessa mikään laki ei nimeä penetraatiotestausta velvollisuudeksi jokaiselle yritykselle, jolla on verkkosivusto.

Kyberturvallisuuslaki, joka tuli voimaan 8. huhtikuuta 2025 ja panee täytäntöön Euroopan unionin direktiivin 2022/2555, asettaa velvollisuuksia toimijoille: ilmoittautumisen toimijaluetteloon, johdon vastuun, riskienhallinnan toimintamallin ja poikkeamista ilmoittamisen. Penetraatiotestausta itse laissa ei nimetä yhdessäkään pykälässä.

Testaamisen nimeää Traficomin suositus NIS-valvoville viranomaisille kyberturvallisuuden riskienhallinnan toimenpiteistä, jolla valvovat viranomaiset arvioivat kyberturvallisuuslain 9 §:n hallintatoimenpiteitä. Se luettelee säännöllisen turvallisuustestauksen tunnetuiksi menetelmiksi, esimerkiksi haavoittuvuusskannauksen, uusien järjestelmien käyttöönoton yhteydessä, merkittävien muutosten jälkeen ja poikkeamien jälkeen, mutta vain niille viestintäverkoille ja tietojärjestelmille, joita toimija käyttää toiminnassaan tai palveluntarjonnassaan. Sama suositus mainitsee penetraatiotestauksen esimerkkinä hankinnan ja kehittämisen turvallisuustestauksessa. Suositus ei sido: sitovat velvoitteet ovat laissa. Sama laki antaa valvovalle viranomaiselle tiedonsaanti- ja tarkastusoikeuden, ja tarkastuksessa viranomainen saa suorittaa tarvittavia testejä; merkittävän poikkeaman tai vakavan laiminlyönnin jälkeen viranomainen voi velvoittaa teettämään turvallisuusauditoinnin.

Nämä ovat kaksi ehtoa yhdessä, ei yksi: yritys, joka ei ole lain soveltamisalaan kuuluva toimija, ei saa tästä kohdasta velvollisuutta, eikä toimija, jonka kyseinen järjestelmä ei ole niitä viestintäverkkoja ja tietojärjestelmiä, joista palvelu riippuu, saa sitä sekään, joten ensimmäinen askel ei ole tarjouksen pyytäminen vaan itsearvio siitä, kuulutko soveltamisalaan ylipäätään.

Miten tiedät, oletko toimija

Kyberturvallisuuslaki ei luettele yrityksiä nimeltä, vaan kuvaa toimialat ja koon, ja velvollisuus arvioida oma asemansa on asetettu yritykselle itselleen, mikä käytännössä merkitsee kahta kysymystä: kuuluuko toimintasi johonkin laissa nimettyyn alaan, ja täyttääkö yrityksen koko säädetyn kynnyksen. Molempiin on vastattava itse, ja vastaus on dokumentoitava — juuri siksi ensimmäinen kulu tällä alueella on yleensä juridinen neuvonta, ei tekninen palvelu.

Jos vastaus on ”ei”, pidemmät kohdat siitä, mistä järjestelmistä palvelu riippuu, eivät koske sinua lainkaan, ja jos vastaus on ”kyllä”, seuraa toinen kysymys siitä, mistä viestintäverkoista ja tietojärjestelmistä palvelusi oikeasti riippuu. Odotus testaamisesta on sidottu näihin järjestelmiin, ei toimijan asemaan sinänsä, ja yritys voi olla toimija, jonka yhdellekään järjestelmälle tämä odotus ei kohdistu.

On myös kolmas tie, joka ei edellytä tiettyä järjestelmää: valvova viranomainen voi tapauskohtaisesti pyytää tietoja tai tehdä tarkastuksen, ja merkittävän poikkeaman tai vakavan laiminlyönnin jälkeen velvoittaa teettämään turvallisuusauditoinnin. Se ei ole suunniteltavissa oleva velvollisuus, mutta se on syy tietää, kuka puolellasi sellaiseen pyyntöön vastaisi.

Muut kynnykset nimeävät testaamisen, eivät penetraatiotestiä

Yleisen tietosuoja-asetuksen 32 artikla edellyttää, että teknisten ja organisatoristen toimenpiteiden tehokkuutta testataan, arvioidaan ja tehostetaan säännöllisesti, ja vaatimuksen laajuus on sidottu riskiin. Se ei ole sama asia kuin velvollisuus tilata penetraatiotesti kerran vuodessa, ja tarjous, joka esittää 32 artiklan sellaisena, kertoo asetuksen vapaammin kuin se on kirjoitettu. Velvollisuus osoittaa, että testaamista ylipäätään tapahtuu, on todellinen; velvollisuus valita juuri tämä testaamisen laji ei seuraa 32 artiklasta.

Maksukorttistandardi PCI DSS nimeää vaatimuksessa 11.4 penetraatiotestin suoraan, kahdentoista kuukauden välein ja merkittävien muutosten jälkeen, mutta se on sopimusperusteinen velvollisuus ja koskee tapaa, jolla otat kortteja vastaan. Verkkokauppa, joka ohjaa maksut kokonaan maksupalveluntarjoajalle eikä itse käsittele korttitietoja, ja muut, joiden ympäristöön korttitiedot päätyvät, vastaavat tähän vaatimukseen eri tavalla. Se on kysymys, johon vastaa vastaanottajapankkisi, ei artikkeli.

Finanssialalla asetus 2022/2554 edellyttää säännöllistä testaamista, ja uhkaperusteisen tunkeutumistestauksen (TLPT) se varaa vain niille yhteisöille, jotka valvoja on erikseen nimennyt. Standardi ISO/IEC 27001 edellyttää haavoittuvuuksien hallintaa ja tietoturvatestaamista nimeämättä penetraatiotestiä; väite, ettei sertifikaattia myönnetä ilman sitä, on yleinen eikä standardista löydy.

Jos yksikään näistä kynnyksistä ei koske sinua, sinulla ei ole säädöksiin perustuvaa velvollisuutta tilata penetraatiotestiä, eikä se merkitse, ettei olisi mitään tehtävää, vaan sitä, että tehtävä on toinen.

Jos yksikään kynnys ei ylity

Yritykselle, joka ei ole toimija, ei käsittele korttitietoja eikä toimi finanssialalla, mielekkäin työ on yleensä se, mitä tapahtuu säännöllisesti, ei kerran kolmessa vuodessa. Se on päivitykset, joilla on vastuullinen ja määräaika; varmuuskopiot, jotka joku on kerran palauttanut ja todennut, että ne todella palautuvat; monivaiheinen tunnistautuminen (MFA) ylläpitäjätilille, jota Traficom suosittelee perustason käytäntönä ja joka on yhtä hyödyllinen muillekin; ja säännöllinen skannaus, jonka tulokset joku todella lukee.

Tämä ei ole pienempi vastausvaihtoehto vaan toisenlainen työ. Valtaosa murtotapauksista, joiden parissa työskentelemme, ei ala hienostuneesta hyökkäyksestä vaan päivittämättömästä komponentista tai salasanasta, joka kelpasi myös toisaalla, eikä penetraatiotesti, joka tapahtuu kerran kolmessa vuodessa, suojaa siltä. Jos verkkosivustosi on jo kärsinyt, järjestys on toinen ja sen kuvaa erillinen artikkeli siitä, miten hakkeroitu verkkosivusto palautetaan.

Penetraatiotesti tulee perustelluksi silloin, kun on jotakin, minkä voi menettää, ja kun menetyksen mittakaava on suurempi kuin testin hinta: järjestelmä, jossa on toisten ihmisten tietoja, integraatio, joka koskettaa rahaa, tai tilaaja, joka vaatii näytön. Siihen asti se on oikea työ väärässä järjestyksessä.

Mitä testin aikana tapahtuu

Työ alkaa laajuuden määrityksestä ja päättyy raporttiin, ja niiden välillä on kolme vaihetta, jotka kannattaa ymmärtää ennen tarjousten vertailua, koska juuri ne selittävät, miksi yksi testi maksaa sen minkä maksaa, ja miksi toinen samasta järjestelmästä maksaa kymmenen kertaa vähemmän.

Ensimmäinen vaihe on tiedustelu, jossa testaaja kerää kaiken sen, mitä järjestelmästä voi ulkopuolelta saada selville — mitkä osoitteet ovat julkisia, mitkä teknologiat ja versiot näkyvät, missä ovat kirjautumislomakkeet, mitkä tiedostot ovat saatavilla ilman tunnistautumista. Tässä vaiheessa ei vielä hyödynnetä mitään, mutta juuri tässä istuvat useimmin löydökset, joita kukaan ei odottanut: unohdettu testiympäristö, avoin hakemistolistaus, varmuuskopio, joka makaa arvattavassa osoitteessa.

Toinen vaihe on itse tarkastus, jossa automaattiset työkalut käynnistetään, jotta tunnettu ei jäisi väliin, mutta päätökset tekee ihminen, joka tarkistaa, onko löydös aito, yrittää hyödyntää sitä ja katsoo, mitä sillä saa. Tässä syntyy ketju — pääsy yhteen tiliin, siitä toimintoon, johon ei pitänyt yltää, siitä tietoihin. Erikseen yksikään askel ei ole dramaattinen; yhdessä ne ovat tarina.

Kolmas vaihe on todistaminen ja kirjaaminen, koska jokaisesta löydöksestä on jäätävä todiste, jonka voi toistaa: mikä pyyntö lähetettiin, mikä oli vastaus, mikä muuttui. Ilman sitä raportti on mielipide, ja kehittäjä, joka sen saa, viettää päivän yrittäessään ymmärtää, mitä testaaja oikeastaan näki.

Siksi myös ajat ovat sellaisia kuin ovat: yhden pienen verkkosivuston testi on muutama päivä, mutta järjestelmä, jossa on useita rooleja, integraatioita ja maksuja, on viikkoja, ja tarjous, joka lupaa täyden penetraatiotestin yhdessä päivässä, kuvaa skannausta eikä testiä.

Miksi tarjoukset eroavat kymmenkertaisesti

Kun kaksi tarjousta samasta verkkosivustosta eroaa kymmenkertaisesti, ero ei juuri koskaan ole katteessa, ja se on lähes aina laajuudessa ja menetelmässä: yksi tarjoaa automaattisen skannauksen työkalulla, joka käynnistetään tunnissa ja jonka raportin sama työkalu tuottaa, mutta toinen tarjoaa viikon ihmisen työtä, jossa työkalut ovat vasta alku, ja juuri tämän eron nimi ”tietoturvatarkastus” molemmissa tapauksissa peittää.

Toinen hintaa muodostava tekijä on järjestelmän monimutkaisuus, ja sen voi arvioida ennen kuin keskustelu alkaa: yksi julkinen verkkosivusto ilman käyttäjätilejä on yksi työ, mutta järjestelmä, jossa on useita rooleja, maksuja, ulkoinen integraatio ja tietoja, jotka kuuluvat asiakkaille, on aivan toinen, koska jokainen rooli on erillinen testattava raja ja jokainen integraatio on paikka, jossa kaksi järjestelmää luottaa toisiinsa enemmän kuin pitäisi.

Kolmas on se, mitä testin jälkeen saat ja kuinka kauan toteuttaja jää paikalle: raportti ilman prioriteetteja, ilman todisteita ja ilman uusintatarkastusta maksaa vähemmän siksi, että se on pienempi työ, ja yritykselle, jonka on sen jälkeen korjattava löydökset, juuri nämä kolme asiaa ratkaisevat, tuleeko asiakirjasta tehtävälista vai kansio, jota kukaan ei enää avaa.

Siksi tarjouksia voi vertailla hinnan mukaan vain silloin, kun laajuus on kirjoitettu samalla tavalla, ja yksinkertaisin tapa saada se aikaan on kirjoittaa laajuus itse ja pyytää kaikkia tarjoamaan sen pohjalta, eikä antaa kunkin toteuttajan määritellä omansa.

Milloin testi vanhenee

Penetraatiotestin tulos kuvaa tiettyä järjestelmää tiettynä päivänä, mikä on itsestään selvää, ja silti juuri tässä syntyy suurin osa väärinymmärryksestä toteuttajan ja tilaajan välillä, koska raportti, joka on vuoden vanha, kuvaa koodia, joka on sen jälkeen muuttunut kymmeniä kertoja.

Säädetyt jaksot myöntävät tämän itse: Traficomin suosituksessa säännöllisen testauksen rinnalla seisoo testaus uusien järjestelmien käyttöönoton yhteydessä ja merkittävien muutosten jälkeen, ja maksukorttistandardissa vuotuisen välin rinnalla seisoo ”merkittävien muutosten jälkeen”, joten molemmissa kalenteri on vain minimi ja varsinainen syy testata on muutos.

Käytännössä se merkitsee, että uusi syy testata on muutos, joka muuttaa hyökkäyspinta-alaa: uusi julkinen toiminto, uusi integraatio ulkoiseen järjestelmään, tunnistautumisen vaihto, siirtyminen toiseen webhotelliin, uusi käyttäjärooli laajemmilla oikeuksilla. Värin vaihto tai tekstin korjaus ei sellaiseksi syyksi muutu, vaikka se olisi kuinka näkyvä.

Toinen syy on se, että ympäristö on muuttunut, ei koodisi: haavoittuvuus kehyksessä, jota käytät, paljastuu testin jälkeen, eikä testi, joka ei sitä maininnut, ole erehtynyt, koska sitä ei tuolloin vielä ollut. Siksi säännöllinen skannaus ja päivitysten prosessi ovat se, mitä tapahtuu testien välillä, eikä testi korvaa niitä.

Ilman omistajan lupaa samat teot ovat lainvastaisia

Penetraatiotesti ei eroa hyökkäyksestä teknisesti, ja ainoa, mikä ne erottaa, on asiakirja: omistajan lupa, jossa on nimetty laajuus, aika ja rajat, ja joka kannattaa panna kirjalliseksi silloinkin, kun laki ei sitä suoraan vaadi. Ilman sitä samat teot ovat samoja tekoja, ja sillä on oikeudellisia seurauksia — Suomessa oikeudeton tunkeutuminen tietojärjestelmään on tietomurto rikoslain 38 luvun 8 §:n mukaan.

Käytännössä se merkitsee, että luvan antaa se, jolle järjestelmä kuuluu, ei se, joka sitä ylläpitää. Jos verkkosivustosi toimii webhotellissa, myös palveluntarjoajan on tiedettävä, että testi tapahtuu, koska muuten sen suojaus pysäyttää testin tai lukitsee tilisi. Jos järjestelmässä on kolmannen osapuolen komponentti, jota et hallitse, se ei kuulu laajuuteen.

Laajuuden rajat on kirjoitettava ennen, ei jälkeen, ja siihen listaan kuuluu, mitkä osoitteet ovat laajuudessa ja mitkä eivät, testataanko tuotantoympäristöä vai kopiota, mitä tapahtuu, jos testi keskeyttää palvelun, ja kuka puoleltasi on tavoitettavissa yöllä; tämä keskustelu vie tunnin ja ratkaisee suurimman osan riidoista, jotka muuten syntyvät kesken testin.

Mitä testi ei ole: punainen tiimi, bug bounty ja vaatimustenmukaisuuden arviointi

Penetraatiotestin rinnalla on useita töitä, joita tapaa kutsua samaksi, eikä ero niiden välillä ole akateeminen vaan käytännöllinen — se ratkaisee, mitä tilaat ja mitä saat.

Punaisen tiimin harjoitus ei tarkista järjestelmää vaan suojausta: huomaavatko ihmisesi ja prosessisi hyökkäyksen ja mitä he tekevät. Laajuus on laajempi, kesto pidempi, ja osa arvosta on juuri siinä, ettei suojautuva puoli tiedä harjoituksen olevan käynnissä. Yritykselle, jolla ei ole mitään huomattavaa, koska kukaan ei lue lokeja, tämä työ on ennenaikainen.

Bug bounty on malli, ei testi: julkaiset säännöt ja maksat löydöksistä niille, jotka ne lähettävät. Se voi löytää sen, minkä yksi testaaja ohitti, mutta se ei anna laajuuden takeita, ei määräaikaa eikä raporttia, jonka voi liittää hankinta-asiakirjoihin.

Uhkaperusteinen tunkeutumistestaus (TLPT) on erillinen, säännelty työ finanssialalla, ja se on määritelty unionin asetuksessa. Jos yrityksesi ei ole valvojan nimeämä finanssiyhteisö, tämä termi ei kuulu tarjoukseesi.

Vielä yksi raja, jonka tapaa pyyhkiä, on se, joka kulkee ”black boxin”, ”white boxin” ja ”grey boxin” välillä — kuinka paljon testaaja järjestelmästä jo alussa tietää. Se on alan sopimus, ei säädöksen vaatimus, ja sillä on suora vaikutus hintaan ja siihen, mitä testi löytää. Testaaja ilman pääsyä jäljittelee vierasta; testaaja, jolla on tili ja dokumentaatio, yltää samassa ajassa pidemmälle. Kumpikaan vaihtoehto ei ole oikeampi; kysymys on siitä, mitä pelkäät.

Mitä saat ja miten sitä luetaan

Testin tulos on raportti, ja sen arvo on prioriteeteissa, ei löydösten määrässä, koska raportti, jossa on sata riviä eikä ole sanottu, mistä aloittaa, on yhtä käyttökelvoton kuin skannerin tuloste. Hyvä raportti kertoo jokaisesta löydöksestä, mitä hyökkääjä sillä voi tehdä, kuinka helposti, ja mitä konkreettisesti muuttaa.

Toinen, mitä on syytä vaatia, on tarkastus korjausten jälkeen, koska löydös, joka on korjattu, ja löydös, jonka joku luulee korjatuksi, eroavat toisistaan, ja ainoa tapa selvittää se on tarkistaa uudelleen. Me teemme sen 30 päivän kuluessa korjauksista, ja tätä määräaikaa kannattaa vaatia jokaiselta toteuttajalta.

Kolmas on se, mitä kehittäjäsi raportilla tekee. Löydös, joka on kuvattu CVE-numerolla ilman kontekstia, merkitsee kehittäjälle etsimistä; löydös, johon on liitetty konkreettinen pyyntö ja paikka koodissa, merkitsee korjausta. Jos toteutuksen tekee yksi yritys ja testin toinen, tämä ero on se, joka ratkaisee, tehdäänkö korjaukset viikossa vai vuosineljänneksessä.

Neljäs on se, mitä raportissa ei saa olla: väite, että järjestelmä on nyt turvallinen. Testi näyttää, mitä sovitussa laajuudessa sovittuna päivänä onnistuttiin tekemään. Se ei todista, ettei ole mitään muuta, ja toteuttaja, joka sen lupaa, myy sinulle lohdutusta.

On vielä yksi syy, miksi tämä keskustelu kannattaa aloittaa aiemmin kuin näyttää tarpeelliselta: testi, joka tapahtuu viikkoa ennen järjestelmän käyttöönottoa, löytää saman minkä olisi löytänyt kolme kuukautta aiemmin, mutta löydösten korjaamiseen ei enää ole aikaa eikä budjettia, ja käytännössä se päättyy listaan, joka hyväksytään riskiksi, ei korjauksiin, siksi Traficomin suosituksen logiikka testata uusien järjestelmien käyttöönoton yhteydessä on kirjoitettu juuri siten kuin se on, ja sama logiikka pätee myös niihin, joita tämä suositus ei sido.

Ja viimeinen, joka kannattaa sanoa suoraan: penetraatiotesti ei ole todistus siitä, että järjestelmä on turvallinen, vaan todistus siitä, että tiettynä päivänä tietyssä laajuudessa tunnettu taito ei löytänyt tietä pidemmälle kuin johonkin tiettyyn, ja siksi raportin arvokkain osa ei useinkaan ole löydösten lista vaan kuvaus siitä, mitä yritettiin ja mikä ei onnistunut, koska juuri tämä osa kertoo seuraavalle testaajalle kolmen vuoden päästä, mistä ei kannata aloittaa nollasta.

Mitä valmistella ennen keskustelua

Jotta tarjous ylipäätään olisi vertailukelpoinen, toteuttajan on tiedettävä laajuus, joten valmista lista osoitteista ja järjestelmistä, jotka siihen kuuluvat, kerro, testataanko tuotantoympäristöä vai kopiota, sano, mikä järjestelmässä on sellaista, johon ei saa koskea, ja nimeä ihminen, joka voi antaa luvan testin keskeyttämiseen.

Tuotantoympäristö vai kopio

Tämä on kysymys, joka ratkaisee sekä hinnan että riskin, koska testi tuotantoympäristössä näyttää sen, mikä todella on saavutettavissa, ja juuri siksi se voi rikkoa jotakin: kuormittaa, täyttää tietokannan testitietueilla, lähettää asiakkaille oikeita sähköposteja tai juuttua suojaukseen, joka estää testaajan ja sen jälkeen myös osan käyttäjistäsi.

Testi kopiossa on turvallisempi ja samalla vajavaisempi, koska kopio harvoin on identtinen: siinä tapaa puuttua todellisia integraatioita, todellista tietomäärää ja todellista konfiguraatiota, ja juuri konfiguraatiossa ongelma usein istuu. Jos valitset kopion, kirjaa, millä se eroaa tuotantoympäristöstä, koska tämä lista on myös lista siitä, mitä testi ei tarkastanut.

Keskiväli, jota käytämme useimmin: lukutoiminnot tuotantoympäristössä, kirjoittavat ja mahdollisesti tuhoavat — kopiossa, etukäteen sovitussa ikkunassa ja ihmisen kanssa, joka voi keskeyttää. Se ei ole kompromissi hinnan tähden vaan tapa saada molempien vaihtoehtojen vastaukset keskeyttämättä työtä.

Kelpaa myös vastakkainen lista, eli se, mikä ei ole laajuudessa, koska ääneen lausumattomat rajat ovat ne, joista myöhemmin riidellään. Kolmansien osapuolten palvelut, joita et ylläpidä, eivät siihen kuulu, ja niiden testaaminen ilman näiden osapuolten lupaa on sama ongelma, josta edellinen jakso kertoo. Jos verkkosivustosi käyttää ulkoista maksuikkunaa, ulkoista keskusteluikkunaa tai ulkoista analytiikkaa, ne ovat toisten omaisuutta, ja tarjous, joka lupaa ”tarkistaa nekin”, lupaa sen, mitä ei saa.

Lopuksi kerro, mitä löydöksille tapahtuu sen jälkeen: kuka ne korjaa, missä ajassa, ja tarkistaako toteuttaja korjausten jälkeen uudelleen. Testi ilman tätä sopimusta päättyy usein asiakirjaan, jota kukaan ei avaa, ja se on kallein mahdollinen versio: maksettu tiedosta, jota ei käytetä.

Kerro myös, mihin etsit vastausta, koska ”meidän on täytettävä vaatimus” ja ”haluamme tietää, pääseekö joku asiakkaiden tietoihin” ovat kaksi eri työtä kahdella eri hinnalla, ja toteuttaja, joka ei kysy, kumpi niistä on sinun, tarjoaa sen, joka on hänelle kätevämpi.

Jos et ole varma, kummalla puolen kynnystä olet, siitä kannattaa aloittaa. Automaattinen auditointi vastaa yleensä kysymykseen tunnetuista heikkouksista halvemmin ja nopeammin kuin manuaalinen asiantuntijatyö, ja sen tulos kertoo myös sen, onko penetraatiotesti seuraava askel. Keskustelu laajuudesta kannattaa aloittaa prosessin kuvauksesta, ei teknologialistasta, koska laajuuden määrää se, minkä menetät, jos järjestelmä pettää.