Olennainen tietoturvaopas tuotepäälliköille

Oletko kuullut Code Spacesista? Se oli GitHubin kaltainen lähdekoodivarasto.

Et todennäköisesti kuitenkaan ole kuullut siitä, koska lupaavasta tuotteesta huolimatta se katosi lähes välittömästi kesäkuussa 2014 valtavan tietoturvaloukkauksen jälkeen. Loukkauksen seurauksena kaikki sen asiakastiedot menetettiin, mikä pakotti yrityksen lopettamaan toimintansa.

Tuon tapauksen jälkeen kaikki digitaalisen maailman toimijat, myös tuotepäälliköt, oppivat läksyn, jota ei pitäisi koskaan unohtaa—TUOTTEIDEN ON OLTAVA TURVALLISIA.

Tässä oppaassa tutustutan sinut tuoteturvallisuuden maailmaan ja autan sinua pitämään turvallisuuden mielessä tuotteitasi hallinnoidessasi.

Miksi tuotepäälliköiden pitäisi välittää tietoturvasta

Teoriassa tuotehallinnan päivittäisen työn pitäisi keskittyä vain käyttäjien pysyvyyteen, käyttäjähaastatteluihin ja muihin ei-teknisiin asioihin ilman huolta tietoturvasta.

Elämme kuitenkin maailmassa, jossa on pahantahtoisia ihmisiä, jotka varastaisivat mielellään tietosi (myydäkseen ne myöhemmin jossain), salaisivat ne, vaatisivat niistä lunnaita (eli kiristyshaittaohjelmia) tai yksinkertaisesti aiheuttaisivat vahinkoa vahingoittamisen vuoksi.

Aktivoinnin ja käyttäjien pysyvyyden lisäksi sinun pitäisi siis välittää myös siitä valtavasta liiketoimintariskistä, jonka löyhä tietoturva voi aiheuttaa tuotteellesi. Riittävän vakava tietoturvaloukkaus vahingoittaa mainettasi niin paljon, että markkinointi-, tuotekehitys- ja myyntitiimiesi vuosien kova työ voi haihtua yhdessä päivässä.

Lisäksi joudut kohtaamaan kumppaneidesi ja asiakkaidesi oikeustoimia, koska et ole onnistunut suojaamaan heidän tietojaan.

Siksi mielestäni on äärimmäisen tärkeää, että tuotepäälliköt ovat “tietoturvatietoisia” rakentaessaan ja kasvattaessaan tuotteitaan.

Tuotekehityksen 4 yleisintä tietoturva-aukkoa

Tuotepäällikkönä sinun ei oikeastaan tarvitse tuntea syvällisesti uusimpia hakkerointimenetelmiä tai keinoja suojautua niiltä. Nämä ovat asioita, jotka tietoturva- ja tekniikkatiimiesi tulee toteuttaa ja hallita.

Sinulla täytyy kuitenkin olla perustason tekninen ymmärrys siitä, miten jotkin yleisimmistä tietoturvaongelmista toimivat ja miten hakkerit voivat hyödyntää niitä. Tämä tekee päätöksentekoprosessistasi “tietoturvatietoisemman”.

Käydään yhdessä läpi neljä tällaista tietoturva-aukkoa ja selvitetään, mistä niissä on kyse.

1. SQL-injektio

Kun olin nuori tuotepäällikkö, päätin opetella hieman ohjelmointia ja tein pienen (ja hirvittävän) PHP-koodin, joka toimi verkkosivuston yhteydenottolomakkeen taustajärjestelmänä. Se vastaanotti viestin, tallensi sen tietokantaan ja laati minulle osoitetun sähköpostin, joka sisälsi viestin sisällön.

Kun näytin tämän kehittäjäystävälleni, hän tuskin pystyi pidättelemään huvittuneisuuttaan (koodini oli yksinkertaisesti käsittämättömän huono) ja kysyi, olinko puhdistanut syötteeni. Kuten arvata saattaa, minulla ei ollut aavistustakaan, mitä hän tarkoitti, joten hän selitti, että tietokantani olivat ilman syötteiden puhdistamista alttiina SQL-injektiolle.

SQL-injektio tarkoittaa prosessia, jossa hakkeri kirjoittaa syötteisiin tekstin sijaan erityistä SQL-koodia, joka päätyy suoritettavaksi taustajärjestelmässäsi ja antaa hänelle luvattoman pääsyn tuotteeseesi tai mahdollistaa tietojen varastamisen tietokannoistasi.

Kuvitellaan, että LinkedIn käyttäisi tätä SQL-kyselyä salasanasi tarkistamiseen kirjautuessasi (huomautus: he tekevät ehdottomasti jotain tässä esitettyä SQL-koodia älykkäämpää).

Jos kirjautumissivun syötteitä ei teoriassa olisi puhdistettu, voisit kirjoittaa ' OR '1'='1 käyttäjätunnus- ja salasanakenttiin ja napsauttaa Kirjaudu sisään -painiketta.

Tässä tapauksessa taustajärjestelmä lisäisi ' OR '1'='1 -merkkijonon SQL-kyselyyn, jolloin kyselystä tulisi jotakin tämän kaltaista.

Tämä kysely palauttaa arvon “true”. Se tarkoittaa, että voisit kirjautua LinkedIniin ilman oikeaa käyttäjätunnusta ja salasanaa.

Kuten jo mainitsin, voit välttää tämän ongelman puhdistamalla syötteesi. Tässä yhteydessä puhdistaminen tarkoittaa sen varmistamista, että kaikkea syötekenttiin kirjoittamaasi käsitellään tavallisena tekstinä, vaikka kirjoittaisit koodia tai SQL-kyselyn.

Puhdistettujen syötteiden ansiosta LinkedIn yrittää etsiä tietokannasta käyttäjää nimeltä ' OR '1'='1 sen sijaan, että suorittaisi koodin. Se ei lopulta löydä käyttäjää ja ilmoittaa virheestä, ettei LinkedInistä löydy tällaista henkilöä.

Huomautus

Tietenkin yllä oleva esimerkki on yksinkertaistus, ja tosielämän kyberhyökkäykset ovat paljon monimutkaisempia. Mutta jos haluat perehtyä teknisiin yksityiskohtiin ja oppia lisää näistä hyökkäyksistä, suosittelen tutustumaan Justin Clarke-Saltin kirjaan SQL-injektiohyökkäykset ja puolustus.

Suojautuminen SQL-injektioilta on yksi perusasioista, joita voit tehdä pitääksesi asiakkaidesi tiedot turvassa ja välttääksesi haitalliset tietovuodot sekä luvattoman pääsyn.

2. Sivustojen välinen komentosarjahyökkäys (XSS)

XSS on toinen yleinen tapa, jolla hakkerit voivat manipuloida tuotettasi ja toimia siinä haitallisesti. Jotta saisit käsityksen siitä, kuinka yleinen XSS on, Positive Technologiesin raportissa arvioidaan, että noin 90 % kaikista verkossa olevista verkkosovelluksista on alttiita tämäntyyppiselle hyökkäykselle.

Mistä siinä siis on kyse? XSS muistuttaa hieman SQL-injektiota siinä mielessä, että hakkerit manipuloivat järjestelmääsi suorittamaan koodia, jota sen ei pitäisi suorittaa. Tässä tapauksessa suoritettava haitallinen koodi ei kuitenkaan ole järjestelmäsi taustajärjestelmässä tai tietokannoissa, vaan käyttöliittymässä.

Yksi hauskoista ja vaarattomista esimerkeistä XSS:stä on Twitterin (kyllä, kutsun sitä yhä Twitteriksi – yrittäkää vain väittää vastaan) uudelleentwiittaava sydänemoji. Se on hauskaa, koska kukaan ei odottanut Twitterin mokaavan niin pahasti, ja vaaratonta, koska ainoa seuraus oli, että se uudelleentwiittasi itsensä.

Tämä hyökkäys oli vain yksinkertainen twiitti, joka sisälsi seuraavan tekstin.

Kuten kuvasta käy ilmi, kyse ei ole tavallisesta tekstistä vaan koodinpätkästä (tarkemmin sanottuna Javascript-koodista ja jQuerystä), jonka lopussa on sydänemoji.

Ennen kuin Twitter korjasi tämän tietoturva-aukon, selaimesi moottori tunnisti twiitin sisällön kelvolliseksi koodiksi, piilotti sen käyttäjältä ja suoritti sen, jos avasit twiitin selaimessasi. Näin ollen kahden koodirivin sijaan näit vain twiitin, jossa oli sydänemoji.

Kun koodi suoritettiin, se kävi läpi sivun HTML-koodin, etsi automaattisesti näytöltäsi uudelleentwiittauspainikkeen ja napsautti sitä.

Tämä tarkoitti, että kuka tahansa twiittiä katsonut uudelleentwiittasi sen automaattisesti – minkä seurauksena suuri osa Twitterin käyttäjistä sai tartunnan.

Kuvittele nyt, ettei kyseessä olisi itsestään leviävä twiitti vaan jotakin haitallisempaa, kuten komentosarja, joka keräisi luottamuksellisia tietoja näytöltäsi ja lähettäisi ne hakkerille. Vaihtoehtoisesti selaimessasi oleva haitallinen koodi voisi ottaa Internet-pankkisovelluksesi hallintaansa ja alkaa siirtää varoja tililtäsi.

Ymmärrät varmasti pointtini – XSS on edelleen erittäin vaarallinen, vaikka se ei pääsisikään käsiksi palvelimiisi ja tietokantoihisi.

Mutta miten tämä koskee sinua tuotepäällikkönä? Saatat esimerkiksi pyytää insinöörejäsi toteuttamaan hienoja ominaisuuksia ja integraatioita, kuten mahdollistamaan verkkosivustollesi muiden välilehtien sisällön tarkastelemisen käyttäjän selaimessa ja tekemään näillä tiedoilla jotakin kiinnostavaa.

Jos teet niin ja tiimisi kieltäytyy rakentamasta tällaista ominaisuutta, älä hämmenny tai sure, sillä pyytämäsi asia olisi pohjimmiltaan XSS-hyökkäys muita sivustoja vastaan.

XSS on kiehtova kyberturvallisuuden osa-alue, ja siitä on olemassa paljon erinomaisia kirjoja, joita voin suositella. Oma suosikkini on Seth Fogien teos XSS-hyökkäykset.

3. Turvattomat ohjelmointirajapinnat

Ohjelmointirajapinnat (eli API:t) ovat viestintäväline palvelimesi ja käyttäjien selaimen tai heidän mobiililaitteessaan tai työpöytätietokoneessaan olevan sovelluksen välillä.

Aina kun palvelimellasi on tarve hakea, tallentaa tai käsitellä tietoja, selain tai sovellus (eli ”asiakasohjelmat”) lähettää palvelimelle pyynnön, joka sisältää tarvittavat tiedot. Tämän jälkeen palvelin suorittaa tehtävän ja palauttaa vastauksen.

Kun käyttäjät esimerkiksi kirjautuvat sisään, asiakasohjelmat lähettävät käyttäjänimesi ja salasanasi ja pyytävät palvelinta todentamaan sinut. Heti kun palvelin on käsitellyt pyynnön, se lähettää takaisin ”onnistui”-viestin sekä sivun sisällön, jonka käyttäjän pitäisi nähdä kirjautumisen jälkeen.

Koska API:t käsittelevät käyttäjätietoja, ne ovat myös alttiita tietoturvahaavoittuvuuksille, jotka voivat johtaa tietojen haitalliseen manipulointiin (esimerkiksi palvelinta pyydetään suorittamaan rahansiirto käyttäjän nimissä) tai tietomurtoon (esimerkiksi palvelinta pyydetään paljastamaan käyttäjän potilastiedot).

Yleisimmät API-haavoittuvuudet ovat:

Ei todennusta: Tässä tapauksessa API ei vaadi asiakasohjelmaa todistamaan henkilöllisyyttään ennen luottamuksellisten tietojen luovuttamista. Kuvittele asian havainnollistamiseksi, että joku menisi pankkiin ja pyytäisi nostamaan rahaa Mark Zuckerberkin tililtä ja kassavirkailija vain vastaisi: ”Toki, kuinka paljon?”

Pyyntöjen määrää ei rajoiteta: Tässä tapauksessa API:t eivät lopeta pyyntöjen käsittelyä, vaikka niitä olisi aivan liian paljon – siis paljon enemmän kuin pitäisi – mikä johtaa palvelimen ylikuormittumiseen ja kaatumiseen. Tällainen liiallinen pyyntöjen tulva syntyy, kun joku yrittää tehdä palvelimillesi DDoS-hyökkäyksen.

Liiallinen tietojen paljastuminen: Tässä API:n vastaukset sisältävät tietoja, joita et oikeastaan halua ihmisten pääsevän käsiksi. Kun esimerkiksi lähetät rahaa jollekin verkkopankin kautta, API:n ilmoitus tapahtuman onnistumisesta voi sisältää myös vastaanottajan tilin saldon, jota sinun ei todellakaan pitäisi nähdä.

Näiden kolmen haavoittuvuuden ratkaisut ovat melko ilmeisiä. Pyydä tunnistautumista, kun tarjoat arkaluonteisia tietoja, rajoita pyyntöjen määrää ja varmista, ettet tarjoa tietoja, joita ei pitäisi olla mukana.

Jos haluat perehtyä API-tietoturvaan hieman syvemmin, voit tutustua Neil Maddenin kirjaan aiheesta.

4. Salausta ei ole

Tietoturvajohtajani toistaa mielellään jatkuvasti, että hyvin toteutettu kyberturvallisuusstrategia näyttää tuotteessa sipulilta – se koostuu useista tietoturvakerroksista tuotteen eri osien ympärillä.

Kaikki tähän asti käsittelemämme asiat olivat pintakerroksen tietoturvariskejä. Niissä käyttäjä ei pääse palvelimillesi tai tietokantoihisi, vaan yrittää hyökätä ”pinnalta”.

Jos hakkeri kuitenkin päätyy jollain tavalla saamaan täyden pääsyn palvelimillesi eli läpäisee ensimmäisen kerroksen, sinulla pitäisi silti olla käytössä toimenpiteitä, joilla suojaat tietokantojasi luvattomalta käytöltä ja pidät myös sisemmät kerrokset suojattuina.

Yksi parhaista tavoista suojata tietosi tässä tilanteessa on salata ne. Tämä tarkoittaa, että vaikka joku pääsisi tietokantoihisi ja lataisi kyseiset tiedot, ne olisivat hänelle pelkkää siansaksaa, koska tiedot on salattu.

Vain yritys tai käyttäjä – nämä kaksi osapuolta, joilla on salausavain – pystyisi purkamaan tuon siansaksan hyödylliseksi tiedoksi. Valitettavasti tietojen salaamisen unohtaminen palvelimilla on kuitenkin erittäin yleistä, ja se on johtanut lukuisiin suuriin tietovuotoihin.

Olen itse nähnyt liian monia verkkosivustoja ja tuotteita, joissa on otettu riski tallentamalla käyttäjien salasanat selväkielisinä – kyseessä on ohjelmistoissa kuolemansyntinä pidetty käytäntö. Tässä tapauksessa paras käytäntö on käsitellä salasana tiivistealgoritmilla, luoda siitä salattu versio eli tiiviste ja tallentaa sen sijaan tämä.

Tämän hienous on siinä, että sekä käyttäjällä että yrityksellä on avain, jolla tiiviste voidaan palauttaa selväkieliseen muotoon ja salasanaa käyttää tunnistautumiseen. Jos hakkeri kuitenkin pääsee tietokantaan ja lataa tiivisteen, sen muuttaminen takaisin alkuperäiseksi salasanaksi veisi häneltä ilman avainta miljoonia vuosia laskentaa. (En vitsaile – tämä on todellinen luku!)

Salaus on toinen kiehtova kyberturvallisuuden osa-alue, johon suosittelen tutustumaan. Erityisesti voit aloittaa perehtymällä siihen, miten julkisen avaimen salaus toimii, sillä koko internet toimii nykyään sen varassa.

Sovellustietoturvan integroiminen tuotteen ja ohjelmistokehityksen elinkaareen

Kun kaikki nämä haavoittuvuudet ja parhaat käytännöt ovat mielessä, keskitytään ilmeiseen kysymykseen, joka sinulla saattaa olla – miten pidän tuotteeni suojattuina tuotepäällikkönä?

Ajattelin, ettet kysyisi koskaan! Tässä on kaksi tärkeää tietoturvan parasta käytäntöä, jotka voivat auttaa sinua:

Turvalliset tuotteet suunnittelusta lähtien

Tämä on kehitysprosessin lähestymistapa, jonka mukaan tietoturvavaatimukset on pidettävä mielessä heti tuotteiden rakentamisen aloittamisesta lähtien, jotta tietoturvatoimenpiteet integroidaan luontaisesti koodiin ja arkkitehtuuriin sen sijaan, että ne lisättäisiin myöhemmin ohjelmistokehityksen elinkaaren aikana.

Jälkimmäinen vaihtoehto on yleensä paljon kalliimpi, eikä se tarjoa samaa suojaustasoa kuin ”luonnostaan” turvallinen ohjelmisto.

Tuotepäällikkönä sinun vastuullasi on siis pyytää kehitystiimiäsi noudattamaan tätä lähestymistapaa ja pidättäytyä siirtämästä taka-alalle asioita, jotka auttavat rakentamaan tietoturvan osaksi tuotetta.

Säännölliset tietoturvatarkastukset

Suurimmalle osalle hallinnoimistani tuotteista tehtiin säännöllisiä tietoturvatestejä, yleensä kuuden kuukauden tai vuoden välein. Testasimme koko tietoturvan tilan, ja siihen sisältyi:

• Penetraatiotestaus
• Uhkamallinnus
• Turvallisuuskontrollien tarkastelu
• Turvallisuusstrategian ja turvallisuusominaisuuksien tarkastelu
• Toimitusketjun ja automaation työnkulkujen tarkastelu
• Koodianalyysi (mukaan lukien käyttämämme avoimen lähdekoodin koodi ja kolmansien osapuolten kumppanuuksien kautta saatu koodi)
• Turvallisuuden tiekartan ja mittareiden luominen
• Riskien arviointi
• ...ja paljon muuta!

Tämä on tärkeää, koska tuotteesi kehittyy jatkuvasti ja saatat vahingossa heikentää ohjelmistosi turvallisuutta lisätessäsi siihen jotain uutta. Säännölliset auditoinnit tunnistavat nämä ongelmat nopeasti ja antavat sinun korjata ja validoida ne – ennen kuin pahantahtoinen toimija löytää ne ensin.

Tuotepäällikkönä tehtäväsi on varata aikaa näille auditoinneille ja niitä seuraaville koodin siivouksille sekä priorisoida ne.

Luota turvallisuusasiantuntijoihisi

Riippumatta siitä, mitä ominaisuutta aiot rakentaa tai millainen toimintasuunnitelma sinulla on kasvutavoitteidesi saavuttamiseksi, varmista aina, että olet käynyt ideasi läpi turvallisuustiimisi kanssa.

Ja kuuntele – sinusta saattaa vaikuttaa siltä, että turvallisuusasiantuntijasi haluavat tehdä tuotteestasi ”yliturvallisen”. Jos he eivät kuitenkaan pidä ideastasi, sinun kannattaa useimmiten harkita siihen muutosten tekemistä. Muutoin riski ei yksinkertaisesti ole sen arvoinen.

Ja kun kerran puhumme asioiden harkitsemisesta, harkitse myös uutiskirjeemme tilaamista, niin saat runsaasti tuotepäälliköille tarkoitettuja oppaita ja artikkeleita suoraan sähköpostiisi!