- Tietoja
- Kirjoittanut: Lea
- Kategoria: Artikkelit
- Osumat: 4959
Joka päivä saamme kuulla ja lukea erilaisista tiedotusvälineistä, kuinka siitä ja siitä verkkosovelluksessa on löytynyt haavoittuvuus (engl. vulnerability). Ammattilaiset seuraavat esimerkiksi Securityfocuksen bugtraq-listaa tai haavoittuvuustietokantaa, jotkut tärkeimmät pääsevät CERT-FI:in listoille ja joistakin saa lukea jopa Helsingin Sanomista tai teksti-TV:stä. Vauhti on aikamoinen, tänään 28.8.2006 ilmestyi Bugtraq-haavoittuvuustietokantaan 29 uutta haavoittuvuutta tai haavoittuvuusryvästä, eikä tämä päivä ole kovin suuri poikkeus. Tämän päivän haavoittuvuuksia löytyi esimerkiksi Linuxin ytimestä, Mozilla-tuoteperheestä (myös siis Firefoxista), Ciscon verkkotuotteista sekä Microsoftin Internet Explorerista.
Mutta mikä oikeastaan on haavoittuvuus? Haavoittuvuus on jonkinlainen virhe, joka antaa uhalle mahdollisuuden toteutua. Haavoittuvuuteen liittyy yleensä myös käsite hyökkäysvektori (engl. attack vector), joka on se konkreettinen reitti, jonka kautta haavoittuvuutta käytetään hyväksi. Hyväksikäyttäjästä yleensä tietoturvapuolella käytetään nimitystä hyökkääjä, tosin sen ei tarvitse välttämättä olla ihminen, joissakin tilanteissa hyökkäys voi tulla esim. luonnonvoimien taholta.
Selvennetään termejä parilla esimerkillä. Otetaan ensin esimerkki varkausuhasta. Uhka on siis se, että voro vie kannettavan tietokoneen. Nyt jos minä jätän kannettavan tietokoneen näkyville autoon, haavoittuvuus on siinä, että tiiliskivi tekee aika pahaa jälkeä auton ikkunan kohdatessaan ja fyysinen turvallisuus murtuu. Varas huomaa tilaisuuden, iskee sivulasin mäsäksi ja kävelee läppärin kanssa vihellellen pois. Tässä tilanteessa hyökkääjä oli varas, haavoittuvuus oli lasien murtumisalttius kiven kohdatessaan ja hyökkäysvektori sivuikkuna. Hyökkäysvektori olisi voinut myös olla takaikkuna.
Samaan tapaan verkkoturvallisuudessa. Viime vuodenvaihteen WMF-haavoittuvuus, josta ei kohusta huolimatta koskaan tullut isoa epidemiaa, oli ongelma WMF-kuvatiedostojen käsittelyssä, joka salli ulkopuolisen koodin suorittamisen kohdejärjestelmässä. Tässä tapauksessa hyökkääjä olisi voinut olla kuka tahansa ulkopuolinen ilkiö, mutta mielenkiintoisinta oli se että tätä haavoittuvuutta olisi voinut käyttää hyväkseen usean hyökkäysvektorin kautta. Riitti, että sai käyttäjän esikatselemaan haittakoodia sisältävää kuvaa, esimerkiksi lähettämällä kuva sähköpostilla tai pistämällä sen web-sivulla tai vaikka antamalla se levykkeellä. Hyökkäysvektoreiksi kelpasi siis lähes mikä tahansa menetelmä tahansa näyttää kuva kohteen tietokoneella.
Jotta uhasta tulisi todellinen tietoturvaongelma, tarvitsemme epäpyhän kolmiyhteyden: hyökkääjän, haavoittuvuuden sekä hyökkäysvektorin. Minkä tahansa näistä eliminoimalla voimme olla turvassa tältä kyseiseltä uhalta. Kuulostaa periaatteessa helpolta, eikö? Mutta ei se ole. Ensinnäkin hyökkääjien eliminointi ei nykyaikaisessa verkostoituneessa liiketoiminnassa onnistu, tai vaikka voisimmekin sulkea ulkopuoliset pois järjestelmästämme, meidän on kuitenkin sallittava käyttö omalle henkilöstöllemme. Toiseksi, haavoittuvuuksien eliminointi on vaikeaa, erityisesti kun tyypillisesti kehittäjä kuulee moisesta vasta kun joku on sen jo löytänyt. Kolmanneksi jää hyökkäysvektoreiden eliminointi, mitä onkin kovasti harrastettu esimerkiksi ovien lukitusten ja palomuurien avulla. Toisaalta tyypilliset verkkosovellushaavoittuvuudet löydetään usein juuri niistä sovelluksen osista, jotka ovat auki maailmalle eli joiden hyökkäysvektori on vapaa. Esimerkkinä erilaisten webbisovellusten haavoittuvuudet nimenomaan webbiyhteyden kautta. Joten tämäkään ei kovin pitkälle auta.
Mikä sitten avuksi? Tässä palaisin oikeastaan tähän kevyesti sivuuttamaani haavoittuvuusten eliminointiin. Niitä on todella hankala eliminoida siinä vaiheessa kun ohjelmisto on jo käytössä, mutta parhaat tulokset saadaankin kun ohjelmiston tietoturvatarpeet määritellään jo ohjelmiston rakennusvaiheessa. Kokemukseni mukaan samantapaiset tekniikat kuin aikaisemmassa kolumnissani mainitut uhka- ja riskianalyysi, auttavat myös ohjelmistojen tietoturvapiirteiden suunnittelussa ja varmistavat sen, että toteutettava tietoturvatoiminnallisuus kohdistuu juuri oikeisiin asioihin eikä järjestelmään rakenneta näennäisturvallisuutta.
Ota yhteys yhteystietosivun kautta jos aihealue kiinnostaa enemmän!
- Tietoja
- Kirjoittanut: Lea
- Kategoria: Artikkelit
- Osumat: 5070
Tietoturvallisuuden kolme perinteistä päämäärää ovat olleet tiedon luottamuksellisuuden, eheyden ja saatavuuden. Tätä joskus kutsutaan CIA-kolmioksi, englanninkielisten termien confidentiality, integrity ja availability alkukirjainten mukaan. Neljäntenä on silloin tällöin mainittu kiistämättömyys (engl. non-repudiation), mutta vaikka se sinänsä on arvokas päämäärä, se on senverran harvinainen ettei se aina ole päässyt luetteloon mukaan.
Yrityksellä, tai millä tahansa organisaatiolla, on myös suojattavia kohteita (engl. assets). Tälle termille ei ole toistaiseksi löytynyt napakkaa suomenkielistä vastinetta, "suojattava kohde" on toki ymmärrettävä mutta ei kovin hyvä. Monasti on ehdotettu suoraa käännöstä "omaisuus", mutta koska suojattava kohde voi olla toimitilojen ja tietokoneiden lisäksi myös mainetta, erilaisia tietomassoja ja myös ihmisiä, omaisuus ei kovin hyvä käännös sekään. Käytetäänpä mitä termiä tahansa, niin suojattavat kohteet ovat hyvinkin erilaisia ja kunkin kohteen tietoturvapäämäärillä voi olla eri tärkeysjärjestys. Esimerkiksi pankkitoimintaa säätelee mm. pankkisalaisuus, joten pankin tietomassoilla luottamuksellisuus on hyvinkin korkealla prioriteeteissa. Toisaalta taas yritykselle, joka tekee elokuvien digitaalisia efektikuvia, ei yhden kuvan vuotaminen ulkopuolisille ole suuri ongelma. Mutta jos yhden taustakuvan renderöinti viivästyy sovitusta aikataulusta, sillä voi olla mittavia seurannaisvaikutuksia muiden siitä riippuvien kuvien tuotannossa. Joten tällaisessa tilanteessa datan ja palvelun saatavuus on tärkeimpiä tekijöitä. Kukin suojattava kohde on siis analysoitava sen osalta, mitkä tietoturvapäämäärät niille ovat kaikkein tärkeimpiä.
Suojattaviin kohteisiin kohdistuu uhkia (engl. threats), jotka ovat mitä tahansa epäsuotuisia tapahtumia. Tietoturvauhat siis tapahtuessaan vaarantavat kohteen tietoturvallisuutta. Olennaista tässä on se, että uhka voi joko toteutua tai olla toteutumatta. Uhkia on kovin monenlaisia, esimerkkejä ovat niin terroristihyökkäykset, roskaposti kuin sähkönsyöttöhäiriötkin. Uhkaan liittyy kiinteästi riskin (engl. risk) käsite. Riski on jonkinlainen arvio siitä, kuinka todennäköinen uhka on toteutumaan organisaation omassa ympäristössä. Tästä onkin lähtöisin yksi terminologinen sekaannus, nimittäin käsitteitä uhka-analyysi (engl. threat analysis) ja riskianalyysi (engl. risk analysis) on varsin usein käytetty ristiin ja rastiin. Itsekin olen todennäköisesti siihen joskus syyllistynyt. Asiaa vuosia pohdittuani olen tullut siihen tulokseen, että on syytä puhua uhka-analyysistä kun toimenpiteen tarkoitus on kerätä suojattaviin kohteisiin liittyviä uhkia, mutta jos tarkoitus on vielä jatkaa ja kuvata uhan todennäköisyyttä ja vakavuutta, voidaan puhua riskianalyysistä.
Riskianalyysissä riskiä voidaan kuvata joko kvantitatiivisesti eli numeroarvoisesti (esim. toteutumistodennäköisyys prosentteina) tai kvalitatiivisesti eli laadullisesti kuvailevasti (esim. "usein"..."joskus"..."hyvin harvoin"). Valitettavasti kvantitatiivisesti tehdyn riskianalyysin tekeminen on vaikeaa, uhille kun on hyvin hankalaa löytää tarkkoja toteutumistodennäköisyyksiä. Usein tehdäänkin niin, että käytetään muutaman portaan, esimerkiksi kolme, sisältävää kvalitatiivista asteikkoa ja löydetyt uhat jaotellaan niiden mukaisesti. Esimerkkejä usein toteutuvista uhista ovat roskapostin saapuminen ja harvemmista vesivahingot konehuoneessa. Tämän yleisyysjaottelun lisäksi kustakin uhasta arvioidaan sen toteutuessaan aiheuttamat vahingot. Vahingon arvioinnissa on tärkeää että ajatellaan yritystä kokonaisuudessaan eikä rajoituta pelkästään suoriin kustannuksiin. Usein tietoturvan vaarantava tapahtuma vaikuttaa välillisesti myös esimerkiksi yrityksen maineeseen. Tämänkään arviointi ei ole aivan eksaktia tiedettä ja varsin usein tähänkin kehitetään yrityksen mukainen muutamaportainen asteikko (esim. "alle 1000 euroa"..."yli 100 000 euroa").
Tästä saadaankin oivallisesti matriisi, johon jokainen uhka, jonka riski ja kustannukset on arvioitu, voidaan sijoittaa. Matriisin merkitys on siinä, että yritysjohdon kanssa keskustelussa voidaan päättää, mitkä matriisin lohkot ovat sellaisia että niissä oleville uhille olisi tehtävä jotakin. Yleensä valitaan tietysti se matriisin osa, jossa olevat uhat ovat sekä hyvin yleisiä että suuria vahinkoja aiheuttavia. Lisäkeskustelua yleensä aiheuttaa se, pitäisikö ottaa työlistalle jotain muitakin matriisin osia ja jos pitää, niin pitääkö työpanosta suunnata niihin riskeihin, joissa on suurempi toteutumistodennäköisyys vai niihin, joissa on suuremmat haittavaikutukset. Itse yleensä suosin pureutumista niihin uhkiin, jotka ovat yleisempiä, sillä niiden ratkaisulla voi olla tietoturvan lisäksi suuriakin vaikutuksia esimerkiksi organisaation tehokkuuteen.
Esimerkkinä voidaan ottaa vaikka roskaposti. Arvioidaan että yhden roskapostiviestin käsittely (havainto, poisto ja seuraavaan siirtyminen) vie noin kolme sekuntia yhdeltä henkilöltä ja jos roskaposteja saapuu esim. 100 viestiä päivässä, yhdeltä henkilöltä menee 300 sekuntia eli noin 5 minuuttia päivässä pelkän roskapostin käsittelyyn. Jos organisaatiossa on sata henkilöä, pelkkä ajan tuhlaus on organisaation tasolla jo 500 minuuttia eli yli 8h päivässä. Siis organisaation työkapasiteetista tuhlautuu yli yhden henkilön työpanos, noin prosentti, pelkkään roskapostin käsittelyyn. Laskemalla tälle käytetylle ajalle hinta voidaan saada selville paitsi roskapostiongelman taloudellinen vaikutus koko yritykselle, mutta myös yläraja roskapostin estopalvelun ostoon käytettävälle summalle. Tämä on yksi esimerkki siitä, miten riskianalyysin tuloksia voidaan käyttää hyväksi mietittäessä sitä, mihin tietoturvatoimenpiteisiin yrityksen voimavarat kannattaa suunnata.
Ja kun uhat on valittu, niin sitten onkin enää jäljellä niiden vastatoimenpiteiden valinta ja mietintä... Tietoverkkouhkien terminologiaa ja luonnetta käsittelen enemmän myöhemmissä artikkeleissa.