English
Kävin elokuun lopulla Open Source Summit Europe -konferenssissa Amsterdamissa pitämässä esityksen ihmisistä ja heistä johtuvista tietoturvahaasteista osana Embedded Linux Conference Europea. Kokosin tähän blogitekstiin tunnelmia konferenssista, sekä lyhyen tiivistelmän omasta esityksestäni.
Mikä ihmeen Open Source Summit Europe -konferenssi?
Kuten teknologiakonferensseissa yleensä, Open Source Summitissakin keskiössä ovat erinäiset paneelikeskustelut ja tekniset esitykset. Open Source Summit itsessään koostuu useammasta pienemmästä konferenssista ja alatapahtumasta, joten jokaiselle löytyy varmasti jotain kiinnostavaa kuunneltavaa. Sulautettujen järjestelmien kehittäjää (kuten minua) kiinnostaa kenties eniten Embedded Linux Conference ja Zephyr Developer Summit. DevOps-kehittäjä puolestaan voi löytää kiinnostavia esityksiä Cloud & Containers tapahtumasta, kun taas johtoasemassa olevia henkilöitä voi kiinnostaa Open Source Leadership -aiheet. Yksi Open Source Summitin vahvuuksista onkin mielestäni se, että tapahtuma kerää kattavasti eri alojen ihmisiä yhteen paikkaan, ja mahdollistaa verkostoitumisen yli toimialarajojen.
Yhden alakonferenssin sisältä voi löytyä kattavasti aiheita, ja esitysten kohderyhmän oletettu osaamistaso vaihtelee. Toiset esitykset saattavat olla aloittelijalle helposti sopivia, kun taas toisissa oletetaan kattavaa ja syvällistä taustatietoa käsiteltävästä aiheesta. Pääsääntöisesti esityksiä pystyi seuraamaan sujuvasti, vaikka kaikki aiheet eivät aivan tuttuja olleetkaan. Pystyn toki puhumaan vain Embedded Linux Conferencesta, jossa vietin eniten aikaa.
Esitysten ja paneelikeskusteluiden lisäksi tarjolla oli messutunnelmaa Solutions Showcasen muodossa. Tämä oli alue, jossa erinäiset avointa lähdekoodia hyödyntävät yritykset saattoivat esitellä toimintaansa. Paikalla oli monenlaisia firmoja: tuttuja teknologiajättejä, pienempiä startuppeja, sekä isompia avoimen lähdekoodin projekteja. Myös sovellusalueet vaihtelivat runsaasti: oli muun muassa tietoturvaa, pilvipuolta, sulareita ja Linux-distribuutioita. Kokonaisuudessaan alue oli kuitenkin verrattain pieni ja aika nopeasti käyty läpi, jos varsinaisten esitysten puolelta ei löytynyt kiinnostavia aiheita. Ilmaisten tarrojen keräilyyn ja ajan kuluttamiseen taukojen aikana alue oli kuitenkin oikein toimiva.
Esityksen aihe: Ihmisten luomat tietoturvaongelmat
Oman esitykseni aihe ihmisten luomat tietoturvaongelmat oli verrattain ”pehmeä” teknologiakonferenssiin. Monesti kyberturvaa suunnitellessa ja uhkamallinusta tehdessä iso kuva saattaa unohtua, ja tuotetta tietoturvakovennetaan vain hypoteettista hyökkääjää ajatellen. Tämä tietoturvakoventaminen ei kuitenkaan ole tuotteen olemassaolon tarkoitus, vaan tuotteen pitäisi yleensä tuottaa jotain arvoa käyttäjälleen. Jos uhkamallinnuksessa jätetään huomioimatta käyttäjät ja muut sisäiset uhkat, hyökkääjät voivat siirtyä käyttämään sisäisiä reittejä saavuttaakseen haluamansa hyödyn sen sijaan, että yrittäisivät murtautua järjestelmään ulkoisten väylien kautta.
Ihmiset tietoturvan tekijöinä
Näin ollen kaikki tuotteen ympärillä olevat ihmiset tulee ottaa huomioon. Karkeasti ottaen nämä ihmiset voidaan jakaa kolmeen ryhmään: kehittäjät, käyttäjät ja hyökkääjät. Kehittäjät kehittävät tuotetta, joko suoraan koodareiden insinöörityötunteina tai epäsuorasti esimerkiksi lakiosaston tai markkinoinnin rooleissa, joilla saattaa olla oma sanottavansa lopputuotteeseen. Käyttäjät puolestaan käyttävät tuotetta yleensä kuten sitä on tarkoitettu käytettävän. Esimerkiksi IoT-ratkaisujen kohdalla käyttäjä voi olla kuluttaja, joka ostaa tuotteen kaupasta. Toisaalta tehtaan automaatiojärjestelmän käyttäjä voi puolestaan olla kyseisen tehtaan työntekijä. Käyttäjä ei aina itse valitse laitteen käyttämistä, mutta tuotteen tarkoitus on yleensä silti tuottaa arvoa käyttäjälleen joko suoraan tai välillisesti.
Sitten ovat tietysti hyökkääjät. Nämä toimijat pyrkivät käyttämään tuotetta omalla tavallaan ja omilla ehdoillaan. Hyökkääjien motivaatio ja taitotaso vaihtelee hyvinkin paljon. Yhdessä ääripäässä ovat harrastelijahakkerit, jotka haluavat kokeilla asioiden murtamista ”huvin vuoksi”. Toisessa ääripäässä ovat valtiolliset toimijat käytännössä pohjattomine resursseineen. Uhkamallinnusta tehdessä kannattaa miettiä, minkälaiset toimijat voivat olla tuotteesta kiinnostuneita. Huomioon kannattaa ottaa myös erikoistapaus: sisäinen uhka. Sisäisessä uhassa käyttäjä tai kehittäjä voi toimia omaa organisaatiota vastaan. Tämä ei aina tapahdu tietoisesti esimerkiksi kostona, vaan henkilöstä voi tulla myös tahattomasti sisäinen uhka esimerkiksi hyökkääjän kalasteluviestien, painostuksen, tai rehellisen vahingon vuoksi.
Ihmisistä aiheutuvat tietoturvaongelmat
Ihmisistä aiheutuu kahdenlaisia tietoturvaongelmia tuotteissa: rajapintaongelmia, ja ihmisten toiminnasta aiheutuvia ongelmia. Rajapintaongelmat ovat puhtaasti teknisiä, ja puhtaasti kehittäjän vastuulla. Näissä rajapinta itsessään on ongelmallinen. Tuotteet tarvitsevat kuitenkin käytännössä aina rajapintoja, jotta ne voivat tuottaa arvoa käyttäjälleen. On kehittäjien tehtävä toteuttaa nämä rajapinnat niin, että ne ovat turvallisia käyttää, eikä niissä ole teknisiä haavoittuvuuksia. Esimerkiksi etäyhteyksien oikeanlainen salaaminen on esimerkki rajapintaan liittyvästä teknisestä tehtävästä. Joko ajan tai osaamisen puutteen vuoksi rajapintoihin voi kuitenkin jäädä puutteita, joita hyökkääjät voivat käyttää hyväkseen.
Toinen ongelmatyyppi, ihmisten toiminnasta aiheutuvat ongelmat, on hankalampi. Nämä eivät ole välttämättä täysin teknisiä, ja kehittäjien lisäksi myös käyttäjät voivat aiheuttaa näitä. Tuotteella on usein jokin oletettu käyttötapa, ja tuote kehitetään näiden oletusten mukaisesti. Ongelmia voi kuitenkin aiheutua, jos oletukset eivät vastaa todellisuutta ja käytännön toiminta eroaa merkittävästi suunnitellusta. ”Parhaassa” tapauksessa tämä epäsuhta aiheuttaa käytettävyysongelmia. Isommat oletusvirheet voivat kuitenkin johtaa jopa tietoturvaongelmiin, jos ihmiset kokevat asetetut tietoturvamekanismit haitallisiksi tai alkavat kehittää omia tapojaan käyttää tuotetta. Ihmiset saattavat esimerkiksi jakaa salasanoja keskenään, jos he kokevat salasanan turhaksi.
Ihmisten odottamaton toiminta saattaa johtaa vaarallisiin virheisiin, jotka voivat vaarantaa tuotteen tietoturvan tai toiminnallisuuden. Näiden vaarallisten virheiden riski olisikin minimoitava tuotetta ja sen kyberturvaa suunnitellessa. On kuitenkin huomioitava, että joskus käyttäjille on mahdollistettava vaarallisia toimia, kuten esimerkiksi laitteen tietoturva-asetusten muokkaaminen. Kehittäjien on näissä tilanteissa pidettävä huoli, että vaarallisen virheen mahdollisuus näissä toimissa on mahdollisimman pieni.
Ratkaisuja
Vaarallinen virhe voidaan pyrkiä estämään joko varmistamalla, että henkilö ei koe tarvetta tehdä tai hän ei pysty tekemään virhettä. Ensimmäinen askel on vähemmän tekninen. Tässä vaiheessa pyritään riittävällä tuotteen ymmärryksellä varmistamaan, että henkilö tietää vaaran paikat järjestelmässä. Kehittäjien tulisi myös ymmärtää, miten käyttäjä aikoo lopulta käyttää tuotetta. Tärkeää on lisäksi organisaation koventaminen ulkoisia vaikutusyrityksiä vastaan, esimerkiksi luomalla selkeät kommunikaatio-ohjeet. Näissä ohjeissa tulisi listata muun muassa mitä kommunikaatiokeinoja organisaatiossa käytetään, milloin käytetään mitäkin keinoja, kuinka kommunikoida muiden organisaatioiden kanssa, ja miten salaisuuksia tulisi jakaa ja käsitellä. Näillä ohjeilla pyritään vähentämään tahattomien sisäisten uhkien syntymistä ulkoisen vaikutuksen seurauksesta.
Joskus henkilö saattaa kuitenkin haluta toimia tavalla, joka todennäköisesti johtaa vaaralliseen virheeseen, joko tahallisesti tai tahattomasti. Tällöin on hyvä varmistaa teknisillä varmistuskeinoilla, että hän ei pysty tähän. Vähimpien oikeuksien periaate on tärkeä, kun mietitään kuinka haitallista toimintaa voidaan ehkäistä.
Henkilö saa käyttöönsä vain oikeudet, jotka hän tarvitsee suoriutuakseen tehtävistään. Vaarallisten toimien varmistaminen on myös tärkeää, jotta henkilö ymmärtää mitä on tekemässä, eikä aiheuta tietämättään virhettä. Valvonta voi auttaa myös vaarallisten toimintamallien havaitsemisessa ja ehkäisemissä. Tuotekehitystasolla on tärkeää huomioida testaus, erityisesti negatiivinen testaus, jotta voidaan olla varmoja tuotteen kyvystä hallita ongelmallisia syötteitä.
Vahinko kuitenkin tapahtuu yleensä väistämättä jossain vaiheessa, ja siihen on myös hyvä varautua ennakolta. Tässä palataankin esityksen alkuun ja uhkamallinnukseen. Uhkamallinnuksessa täytyy ottaa huomioon pahin mahdollinen skenaario. Tämä tilanne monesti sisältää korkeilla oikeuksilla toimivan sisäisen toimijan virheitä. Kerrostettu tietoturva, jossa monella tasolla toimivat suojausmekanismit tukevat toisiaan, auttaa hyökkäysten vaikutuksien minimoinnissa. Samoin järjestelmien rajaaminen ja eristäminen. Oleellista on myös suunnitella, kuinka virhetilanne pystytään havaitsemaan, ja kuinka siihen puututaan havainnon jälkeen. Lopulta, kun hyökkäys on ohitse, on pystyttävä palauttamaan tuote normaalitilaan, jossa sen tietoturvaan voidaan jälleen luottaa.
Mistä sitten lähtisi tätä vyyhtiä purkamaan? Ensimmäisenä voi olla tarpeen tunnistaa oma tämänhetkinen tilanne: onko organisaatio toistuvasti ulkoisen vaikutusyrityksen kohteena, tai kohdistuuko tuotteisiin jo aktiivisia hyökkäyksiä? Jos kyllä, niin näiden ongelmien ratkominen on hyvä ensimmäinen askel. Kannattaa varmistaa, että kommunikaatio organisaatiossa on selkeää, ja käytössä ovat oikeanlaiset tietoturvatyökalut, jotka auttavat analysoimaan tilannetta ja kehittämään sekä tuotetta että organisaatiota. Jos tilanne on tällä hetkellä hallinnassa, voi olla hyvä idea alkaa proaktiivisesti käydä lävitse tuotteessa olevia rajapintoja. Näistä tulisi varmistaa, että ne ovat turvallisesti toteutettuja, ja niitä käytetään oikein. Jos teknisessä toteutuksessa on puutteita, tulisi kehittäjien korjata rajapinnat, ja jos odotukset käyttötavasta eivät täsmää, tulisi rajapintaa joko muuttaa tai sen käyttäjiä ohjeistaa.
Kerrostetun tietoturvan hengessä kannattaa myös tarkastella teknisempiä rajapintoja, jotka eivät ole ulospäin suoraan ihmisten näkyvissä. Mitä tapahtuu, jos yksi rajapinnoista lakkaa olemasta luotettava? Luottavatko järjestelmässä alemmalla tasolla olevat rajapinnat sokeasti, että niitä käytetään aina oikein? Tätä kysymystä riittävän kauan esittämällä voi päätyä aika matalallekin tasolle järjestelmässä, mutta toisaalta, hyvät tuotteet ovat kauttaaltaan tietoturvakovennettuja, eivät pelkästään reunavyöhykkeiltä.
Tärkeintä on kuitenkin aina muistaa iso kuva tuotteen kyberturvaa pohtiessa. Ei pelkästään sitä, mitä hyökkääjät mahdollisesti tekevät, vaan myös se, mitä varsinaiset käyttäjät tuotteella tekevät.
