Penetraatiotestauksen tarkoitus on selvittää, voiko järjestelmän suojauksia kiertää sovitussa tilanteessa ja mitä siitä seuraisi. Hyödyllinen toimeksianto alkaa kysymyksestä, johon tilaaja tarvitsee vastauksen. ”Testatkaa verkkopalvelumme” ei vielä kerro, tarkastellaanko kirjautumatonta käyttäjää, asiakkaiden erottamista, ylläpidon oikeuksia vai häiriöiden havaitsemista.
Tässä oppaassa kuvitteellinen Projektiranta Oy tilaa asiakasportaalin penetraatiotestin ennen uuden tiedostojakotoiminnon avaamista. Esimerkki kattaa rajauksen, luvan, toteutuksen yhteydenpidon, täytetyn havainnon ja korjauksen jälkitarkistuksen. Se auttaa arvioimaan myös sitä, mitä raportin perusteella voidaan perustellusti väittää palvelun turvallisuudesta.
Penetraatiotesti, haavoittuvuusskannaus ja tavallinen tarkistus
Haavoittuvuusskannaus etsii tyypillisesti tunnettuja puutteita ja poikkeavia asetuksia. Penetraatiotestauksessa asiantuntija arvioi sovittuja hyödyntämismahdollisuuksia ja voi yhdistää havaintoja tapahtumaketjuksi. Tavallinen toiminnallinen turvallisuustarkistus puolestaan varmistaa esimerkiksi, että poistettu käyttäjä ei enää kirjaudu palveluun.
NCSC:n ohje korostaa penetraatiotestin käyttämistä haavoittuvuuksien hallinnan arviointiin. Sen ei pitäisi olla ainoa hetki, jolloin organisaatio etsii puutteita. Myös testin rajaus, ajankohta ja testaajan saamat tiedot vaikuttavat tulokseen. NCSC:n penetraatiotestauksen tilaamisohje.
Projektiranta korjaa jo tiedossa olevat vanhat ohjelmistoversiot ennen toimeksiantoa. Ulkopuolisen asiantuntijan työaikaa ei käytetä ensisijaisesti vahvistamaan puutteita, jotka oma inventaario jo osoittaa. Testin pääkysymys on sen sijaan uusi: pysyykö yhden asiakkaan tiedosto suojattuna toisen asiakkaan tunnuksella myös silloin, kun linkkiä käytetään eri reittejä pitkin?
Mitä laki edellyttää testaukselta?
GDPR:n 32 artiklaan kuuluu menettely teknisten ja organisatoristen toimenpiteiden tehokkuuden säännölliseen testaamiseen, tutkimiseen ja arviointiin. Säännös ei määrää jokaiselle yritykselle tietynnimistä penetraatiotestiä kerran vuodessa. Menetelmä ja toistaminen valitaan käsittelyn riskien ja toteutuksen perusteella. GDPR:n 32 artikla.
Toimialakohtaiset velvoitteet arvioidaan erikseen. Esimerkiksi DORA:n sietokykytestaus sisältää oman soveltamisalansa ja erityiset testausjärjestelynsä. Tavallinen asiakasportaalin testi ei ole automaattisesti tällainen testi eikä sertifikaatti koko organisaation vaatimustenmukaisuudesta.
Projektiranta määrittelee testausluvan kirjallisesti ennen aloittamista. Se varmistaa myös, että sillä on oikeus sallia kyseisten ympäristöjen ja palvelujen testaaminen. Pilvipalvelun tilaaminen ei yksin anna oikeutta kohdistaa kokeita toimittajan muihin asiakkaisiin tai yhteiseen infrastruktuuriin. Mahdolliset palveluntarjoajan testauskäytännöt selvitetään ennen kohteen sisällyttämistä toimeksiantoon.
Täytetty rajaus asiakasportaalille
Projektiranta käyttää kahta keinotekoista asiakasorganisaatiota ja kolmea testiroolia. Aineistossa ei ole oikeiden asiakkaiden asiakirjoja. Koeympäristön erot tuotantoon kirjataan, jotta tulosta ei sovelleta oletuksena ominaisuuksiin, joita siellä ei ollut.
| Rajauksen osa | Projektirannan päätös |
|---|---|
| Kohde | Asiakasportaalin uusi tiedostojako ja siihen liittyvä rajapinta koeympäristössä |
| Tavoite | Selvittää asiakkaiden erottaminen, linkkien pääsynhallinta ja oikeuden päättymisen vaikutus |
| Käyttäjät | Asiakas A:n jäsen, asiakas B:n jäsen ja projektin omistaja |
| Lähtötiedot | Arkkitehtuurikuva, roolit ja tunnetut puutteet annetaan testaajalle |
| Aineisto | Synteettiset tiedostot ja tunnisteet, erilliset testitilit |
| Rajan ulkopuolella | Tuotannon kuormittaminen, henkilöstöön kohdistuva huijaus ja ulkopuolinen maksupalvelu |
| Keskeytys | Väärän ympäristön yhteys, oikea asiakastieto tai odottamaton palveluhäiriö |
| Tulos | Johtoyhteenveto, toistettavat havainnot, rajaukset ja sovittu jälkitarkistus |
Työn tilaaja, tekninen omistaja ja testausryhmä hyväksyvät saman version. Ylläpito merkitsee koeympäristön tunnistettavasti myös palvelinten asetuksiin. Pelkkä selaimen osoiterivin väri ei ole riittävä suoja vahingossa tuotantoon kohdistuvalta työltä.
Täydet lähtötiedot valitaan tässä siksi, että toimeksianto selvittää asiakaserottelun toteutusta rajatussa ajassa. Tilaaja ei pidä tiedon salaamista automaattisesti laadukkaampana testinä. Jos tavoitteena olisi ulkopuolisen hyökkääjän näkökulma tai havainnointikyky, asetelma ja sen rajoitukset olisivat erilaiset.
Vertaa tarjouksia samalla tehtävällä
Projektiranta saa kaksi tarjousta. Ensimmäinen sisältää ulkoisen verkkopinnan skannauksen ja automaattisen raportin. Toinen sisältää sovitut asiakasroolit, tiedostojen pääsynhallinnan asiantuntija-arvion ja löydösten läpikäynnin kehittäjän kanssa. Yritys ei vertaile vain kokonaishintaa, koska ensimmäinen tarjous ei vastaa sen pääkysymykseen asiakkaiden erottamisesta kirjautumisen jälkeen.
Ennen valintaa tilaaja pyytää esimerkin tunnisteista puhdistetusta raportista ja selvittää, kuka työn tekee. Tarjouksessa täsmennetään varsinainen testaus, raportointi, havaintojen selventäminen ja jälkitarkistus erillisinä osina. Jos jälkitarkistus ei sisälly työhön, sille varataan toteutus jo hankinnassa. Testaajan tutkinto tai sertifikaatti voi tukea osaamisen arviointia, mutta se ei korvaa kokemusta kyseisen kaltaisesta portaalista.
Projektiranta valitsee tehtävää vastaavan tarjouksen ja nimeää omat henkilönsä korjausten käsittelyyn. Näin ostettu työ ei pääty raporttiin, jota kukaan ei osaa yhdistää järjestelmän kehitysvastuisiin.
Valmistelu ratkaisee, voiko tulokseen luottaa
Projektirannan järjestelmäkartta osoittaa portaalin, tiedostovaraston ja tunnistuspalvelun yhteydet. Kartta auttaa huomaamaan, että yksi vanha latausreitti käyttää erillistä valtuutusta. Ilman tätä tietoa testi voisi kattaa vain uuden käyttöliittymän ja jättää todellisen rinnakkaisen reitin avoimeksi.
Ennen aloittamista sovitaan tekninen yhteyshenkilö ja varahenkilö, joiden tavoitettavuus on varmistettu testijaksolle. Testiryhmä saa selkeän keskeytyskanavan. Jos kriittinen havainto löytyy ensimmäisenä päivänä, sen ilmoittamista ei siirretä loppuraporttiin.
Myös tunnusten voimassaolo, aineiston poistaminen ja raportin jakelu sovitaan. Testaajalle ei anneta pysyviä yleisiä ylläpitotunnuksia varmuuden vuoksi. Tarvittava korotettu pääsy rajataan omaan vaiheeseensa. Henkilötietojen käsittelyrooli ja mahdollinen käsittelysopimus arvioidaan sen perusteella, mitä testipalvelu todella käsittelee.
Testin aikana havaittu uusi kohde ei kuulu lupaan automaattisesti
Harjoituksessa testaaja huomaa portaalin kutsuvan vanhaa tiedostojen esikatselupalvelua. Palvelua ei ole nimetty toimeksiannossa. Hän ilmoittaa havainnon yhteyshenkilölle ja keskeyttää siihen kohdistuvan lisäselvityksen. Tilaaja varmistaa omistajan ja päättää, muutetaanko rajausta.
NCSC:n ohje käsittelee vastaavaa tilannetta: ulkopuolinen komponentti voi johtaa sovittuun laajennukseen tai raportoitavaan rajoitukseen. Ohjeessa kuvattu toimeksiannon hallinta auttaa tekemään päätöksen tietoisesti. Projektiranta lisää tässä harjoituksessa palvelun vasta erillisen hyväksynnän ja ympäristövarmistuksen jälkeen.
Jos testaus joudutaan keskeyttämään, raporttiin kirjataan tekemättä jäänyt osa. ”Ei havaintoja” ja ”ei testattu” eivät tarkoita samaa. Aikarajan täyttyminen ei myöskään tee jäljelle jääneestä toiminnosta turvalliseksi todettua.
Täytetty havainto: vanha linkki säilyttää pääsyn
Testiryhmä kirjaa havainnon PR-04: poistettu projektijäsen voi edelleen avata aiemmin saamansa tiedostolinkin. Kyseessä on kuvitteellinen tulos synteettisellä aineistolla. Raportissa nimetään testattu versio, projektijäsenyyden tila, käytetty testirooli ja havaittu tiedoston saatavuus.
Odotettu toiminta oli, että projektin omistajan poistama jäsen menettää pääsyn projektin tiedostoihin. Havaittu toiminta oli, että käyttöliittymä ei enää näyttänyt projektia, mutta aiemmin luotu linkki avasi tiedoston edelleen. Näyttö tallennettiin siten, että synteettinen tiedosto ja tapahtuma voidaan yhdistää, mutta raportti ei sisällä toimivaa tuotantolinkkiä.
Vaikutus kuvataan liiketoiminnan kannalta: pääsyn päättyminen ei toteudu kaikilla reiteillä. Vakavuusarvio huomioi linkin käyttöehdot, voimassaolon, mahdollisen edelleenjakamisen ja tiedostojen sisällön. Tiimi ei anna yksittäistä teknistä pistettä koko päätöksen korvikkeeksi. Kyberriskien arviointi täydentää havaintoa palvelun todellisilla vaikutuksilla.
OWASP:n raportointiohje suosittelee erottamaan johdolle tarkoitetun yhteenvedon teknisistä havainnoista ja kuvaamaan rajauksen, rajoitukset, vaikutukset sekä korjauskeinot ymmärrettävästi. Ohje on raportointiin sovellettava malli, ei lakisääteinen raporttimuoto. OWASP WSTG 4.2:n raportointiohje.
Korjaus suljetaan jälkitarkistuksella
Projektiranta estää uuden jakotoiminnon avaamisen, kunnes PR-04 on käsitelty. Kehittäjä korjaa pääsyn tarkistuksen tiedoston tarjoavassa palvelussa. Pelkkä linkkipainikkeen piilottaminen käyttöliittymästä ei ratkaisisi havaittua ongelmaa.
Jälkitarkistuksessa poistettu jäsen ei enää avaa vanhaa linkkiä. Lisäksi aktiivinen jäsen saa edelleen oman tiedostonsa ja toisen asiakkaan jäseneltä pääsy torjutaan. Näin korjauksen vaikutus ja tavoiteltu käyttö arvioidaan yhdessä. Tulos kirjataan alkuperäiseen havaintoon: toteutuksen versio, tarkistuksen rajaus, havaittu toiminta ja mahdolliset jäljelle jäävät ehdot.
Raportin tilaksi ei kirjoiteta ”koko portaali turvallinen”. Suljettu on kyseinen havainto tarkastetussa toteutuksessa. Jos tuotanto käyttää eri tiedostopalvelun asetuksia, niiden vastaavuus on vielä varmistettava ennen käyttöönottoa. Tämä tieto liitetään teknisten ja organisatoristen turvatoimien kuvaukseen.
Raportin käsittely ja testijälkien siivous
Raportti voi sisältää yksityiskohtia, jotka helpottavat puutteen väärinkäyttöä. Projektiranta antaa täyden raportin vain korjaaville asiantuntijoille ja nimetyille päätöksentekijöille. Asiakkaalle annettava yhteenveto kertoo testin kohteen, ajankohdan, olennaiset tulokset ja rajoitukset paljastamatta tarpeettomia teknisiä yksityiskohtia.
Työn päättyessä testitilit suljetaan, väliaikaiset pääsyt poistetaan ja testiaineistojen kopiot käsitellään sovitusti. Raportin säilyttäminen ja testiryhmän työaineiston säilyttäminen ratkaistaan erikseen. Lokituksen avulla erotetaan testin tunnetut tapahtumat todellisista epäilyistä, mutta lokimerkintöjä ei poisteta automaattisesti vain siksi, että ne liittyivät testiin.
Jos oikeaa asiakastietoa tuli testissä odottamatta näkyviin, tapahtuma selvitetään organisaation tietoturvaloukkausten käsittelyprosessissa. Testauslupa ei poista tarvetta arvioida todellista henkilötietojen vaarantumista. Selvityksessä erotetaan havaittu pääsy, mahdollinen aikaisempi altistuminen ja tiedon puutteet.
Miten seuraava testi kohdennetaan?
Projektiranta liittää löydöksen juurisyyn omaan kehitystyöhön: tiedoston näyttämisen oikeus tarkistettiin eri kohdassa kuin projektin jäsenyys. Vastaavat reitit kartoitetaan ja toiminnalliset tarkistukset lisätään järjestelmän omaan kehitysmenettelyyn. Seuraava ulkopuolinen testi voi tämän jälkeen keskittyä uusiin riskeihin.
Toistamisen tarvetta arvioidaan olennaisten muutosten, uusien riippuvuuksien ja havaittujen puutteiden perusteella. Pelkkä säännöllinen tilauskalenteri ei korvaa tätä arviota. Projektirannan lopputulos on tarkasti rajattu näyttö, korjattu pääsynhallintavirhe ja parannettu oma tarkistusmenettely. Niillä on käyttöarvoa myös testausjakson jälkeen.