Viime aikoina bug bounty -ohjelmat ovat herättäneet useissa yrityksissä mielenkiintoa ja keskustelua. Onnistunut bug bounty -ohjelma vaatii yritykseltä laadukkaita prosesseja koko ohjelman elinkaaren aikana. Kokemuksemme mukaan ohjelmien haasteisiin ei aina yrityksissä osata varautua, eikä ohjelmista näin ollen saada täyttä hyötyä.
Mitä sitten onnistuneen bug bounty -ohjelman luomiseen tarvitaan – mitkä ovat ohjelman edellytykset ja mitä se maksaa?
Mikä ihmeen bug bounty?
Bug bountyt ovat ohjelmia, joiden avulla yritykset ja organisaatiot maksavat hakkereille tietoturvaongelmien vastuullisesta raportoinnista. Näin yritykset saavat itse tiedot mahdollisista tietoturvaongelmista, ja niihin pystytään puuttumaan. Usein ohjelmien pyörittämiseen käytetään sitä varten suunniteltua alustaa, jossa yritykset ja hakkerit kohtaavat – näitä ovat esimerkiksi HackerOne ja hackr.fi.
Ohjelmassa järjestävä taho, eli yritys tai organisaatio, luo säännöt, joissa kerrotaan mitkä palvelut ovat ohjelman skoopissa ja millä säännöillä kohdetta saa testata. Järjestäjä määrittelee hakkereille maksettavat palkkiot, sekä ohjelman julkisuuden tai yksityisyyden. Julkisessa ohjelmassa kuka tahansa voi osallistua testaukseen ja raportoida havainnoista. Yksityisessä ohjelmassa puolestaan kutsutaan vain tietyt henkilöt testaamaan palvelua.
Prosessit kuntoon
Menestyksekäs bug bounty -ohjelma vaatii ohjelman järjestävältä organisaatiolta valmistelua. Se ei pelkästään riitä, että rekisteröidytään alustaa tarjoavaan palveluun ja julkaistaan ohjelma siellä. Kun raportteja alkaa tulla, niin miten niihin kyetään reagoimaan, jotta ongelmat saadaan korjattua? Onko ohjelman skooppia mietitty? Kuka kommunikoi hakkereiden kanssa, analysoi havaintojen kriittisyyden, todentaa havaintojen oikeellisuuden ja päättää maksujen suuruudesta?
Ennen bug bounty -ohjelman julkaisemista tulisi varmentua riittävästä tietoturvan tasosta. Skoopissa mukana olevat palvelut olisi hyvä testata ennen ohjelman julkaisua ja tunnetut tietoturvaongelmat korjata, sillä muuten ohjelmasta ja sen kustannuksien arvioinnista tulee käytännössä mahdotonta ja hakkereiden lähettämien havaintojen määrään tukehdutaan. Ensimmäisenä on siis varmennettava riittävä kypsyystaso tietoturvan osalta ja tunnettava mukana olevien järjestelmien turvallisuustilanne.
Bug bounty -ohjelmaan lähdettäessä on aina mietittävä prosessit ja toimintatavat kuntoon. Ainakin seuraaviin asioihin tulisi löytyä vastaus:
- Onko ohjelman skooppi luotu ja varmennettu?
- Onko ohjelman säännöt mietitty ja luotu?
- Tuleeko ohjelma olemaan julkinen vai kutsupohjainen?
- Kuinka paljon havainnoista halutaan maksaa?
- Kuka seuraa hakkereiden tekemiä havaintoja ja kommunikoi heidän suuntaansa?
- Onko organisaatiossa osaamista varmentaa raportoitujen havaintojen oikeellisuus, ja kuka sen tekee?
- Kuka arvioi havaintojen kriittisyyden? Mitä kriteeristöä käytetään?
- Miten sovelluskehittäjille kommunikoidaan havainnoista?
- Onko muita tahoja, joille ohjelmasta täytyy ilmoittaa tai joilta tarvitsee lupia – esimerkiksi kapasiteettipalveluiden tarjoajat (Amazon, jne.)?
- Miten varmennetaan, että raportoidut havainnot tulee myös korjattua?
On äärimmäisen tärkeää, että nämä asiat on mietitty ja varmennettu ennen bug bounty -ohjelman julkaisemista, sillä muuten ohjelmasta ei saada juurikaan hyötyä. Pahimmassa tapauksessa aiheutetaan riskejä, jos esimerkiksi kapasiteettipalveluntarjoajan kanssa asioista ei ole sovittu etukäteen. Ennen ohjelman julkaisemista tulee myös varmentaa, että palvelun liiketoiminnalliset tavoitteet eivät vaarannu ja esimerkiksi palvelun saatavuus ei ole uhattuna. Tämä puolestaan edellyttää tehokkaampaa valvontaa ja saatavuuden seurantaa.
Tarjoavatko bug bountyt oikotien onneen?
Saadakseen hyvät hakkerit kiinnostumaan, on bug bounty -ohjelman oltava riittävän houkutteleva hakkereille – palkkioiden on oltava kilpailukykyisiä ja skoopin riittävän laaja. Tämä puolestaan lisää väistämättä ohjelman kustannuksia. On myös hyvä huomioida, että huipputekijöitä on rajallinen määrä ja suuri massa taas koostuu hyvin pitkälti automaattisia työkaluja käyttävistä tahoista, jotka ovat helpon rahan perässä. Näiden tahojen kanssa kommunikointi voi vaatia yllättävänkin paljon aikaa, vaikka kyseiset tahot eivät tuokaan merkittävästi lisäarvoa yritykselle.
“Bug bounty -ohjelmien yksi suurimmista haasteista on kustannusten vaikea ennustettavuus.”
Olemme huomanneet, että asiakkaillamme on suuria haasteita saada raportoituja havaintoja korjattua. Järjestävän tahon kannalta skoopissa olevien palveluiden tietoturvan parantaminen on tärkein tavoite, joka valitettavan usein jää täyttymättä. Jos näin ei tapahdu, ohjelmaan käytetyt rahat sekä resurssit ovat menneet hukkaan.
Bug bounty -ohjelmien yksi suurimmista haasteista onkin kustannusten vaikea ennustettavuus. On hyvä huomioida, että kustannukset eivät rajoitu pelkästään hakkereille suoritettaviin maksuihin – myös sovelluskehittäjä laskuttaa korjauksista jotain, ja omienkin resurssien käyttö maksaa. Hyvänä nyrkkisääntönä voisi sanoa, että palkkioina maksetut summat voidaankin kertoa ainakin kahdella, niin saadaan karkea arvio kustannuksista. Jos esimerkiksi palkkioita maksettaisiin vuodessa 20 000 eurolla, niin kokonaiskustannukset olisivat tällöin 40 000 euroa. Voidaankin siis sanoa, että bug bounty -ohjelmat eivät tarjoa oikotietä onneen haavoittuvuuksien löytämisessä, mutta ohjelman avulla voidaan saada tietoon tietoturvaongelmia, joita esimerkiksi normaalissa tietoturvatestauksessa ei olisi löytynyt.
Ja hyödyt?
Vaikka bug bounty -ohjelmien pyörittäminen vaatii usein taloudellisia panostuksia sekä resursseja järjestävältä taholta, on hyvin järjestetystä ohjelmasta valtavasti hyötyä. Ohjelma saattaa tuoda havaintoja, joita ei ole havaittu normaaleissa auditoinneissa, sillä yksittäinen hakkeri saattaa käyttää yksittäisen havainnon löytämiseen huomattavan määrän aikaa. Näin syvällinen yhden haavoittuvuuden etsiminen ei yleensä ole aikataulullisesti mahdollista auditoinneissa.
Suuri hyöty ohjelmista järjestäjille on myös niissä tapauksissa, jossa kerran vuodessa tehtävä tietoturvatestaus ei tuo riittävää varmuutta. Jos esimerkiksi palvelusta tehdään uusia julkaisuja päivittäin, on kerran vuodessa tehtävä testaus melko nopeasti vanhentunut. Tällöin bug bounty -ohjelmalla voidaan järjestelmää testauttaa 365 päivää vuodessa, ja maksaa vain tehdyistä havainnoista.
Haavoittuvuuksien löytämisen lisäksi hyvin toteutetut ohjelmat tuovat myös lisäarvoa brändille, ja ne voivat vaikuttaa positiivisesti yrityksen imagoon sekä auttaa osaajien rekrytoimisessa. Ohjelmien hyöty ei siis rajoitu pelkästään yrityksen tietoturvan parantamiseen, vaan sillä on myös monia hyötyjä viestinnällisesti.
Audit vai bug bounty?
Näitä kahta ei pitäisi pitää toisiaan pois sulkevina vaihtoehtoina. Jos vain toinen näistä on vaihtoehto, niin auditointi eli tietoturvatestaus tuo paremman näkymän kokonaisuuteen ja samalla toistettavan testausprosessin, joka toteutetaan ammattilaisen toimesta. Bug bounty -ohjelmassa näitä ei valitettavasti voida taata, kuten ei myöskään sitä, että järjestelmää on testattu ammattimaisesti.
Jos resursseja ja kypsyyttä organisaatiossa riittää, niin bug bounty -ohjelma tuo lisää syvyyttä auditointien päälle. Säännöllisellä tietoturvatestauksella tulee kuitenkin varmentaa palveluiden tietoturvan perustaso – tällöin myös kustannukset ovat huomattavasti paremmin arvioitavissa. Jos päädytään pelkkään bug bounty -ohjelmaan ilman tietoturvatestausta, otetaan merkittäviä riskejä käsiin räjähtävien kustannusten muodossa. Tällöin ei ole mitään käsitystä palveluiden tietoturvatasosta tai siellä olevista haavoittuvuuksista, ja hakkerit voivat saada lukuisia helppoja osumia – ja jos ohjelma halutaan pitää uskottavana, on näistä havainnoista myös maksettava.
Kuinka tuomme lisäarvoa bug bounty -ohjelmaanne?
2NS auttaa omia asiakkaitaan bug bounty -ohjelmien käynnistämisessä sekä pyörittämisessä. Autamme asiakasta muun muassa varmentamaan, että bug bounty -ohjelmassa tarvittavat prosessit ovat kunnossa ennen ohjelman käynnistämistä. Tarjoamme myös apua havaintojen analysointiin, varmentamiseen sekä hakkereiden kanssa kommunikointiin. Ota meihin yhteyttä, autamme sinua arvioimaan bug bounty -ohjelman mielekkyyttä ja mahdollisia riskejä, ja toimimme kumppaninasi ohjelman käynnistämisessä sekä pyörittämisessä!
Juho Ranta
Juho Ranta (CISA, CISM, CISSP, CRISC) on 2NS:n teknologiajohtaja ja yksi yrityksen perustajista. Juholla on mittava kokemus organisaatioiden tietoturvan kehittämisestä ja hänen erityisosaamiseensa kuuluvat tekninen sekä hallinnollinen tietoturva.