Tietoturvan mallintaminen Tea Silander Helsinki 2.3.2005 Tietojenkäsittelytieteen Laitos HELSINGIN YLIOPISTO Tietoturva: luottamus ja varmuus -seminaari
HELSINGIN YLIOPISTO HELSINGFORS UNIVERSITET UNIVERSITY OF HELSINKI Tiedekunta/Osasto Fakultet/Sektion Faculty/Section Laitos Institution Department Matemaattisluonnontieteellinen tdk Tietojenkäsittelytieteen laitos Tekijä Författare Author Tea Silander Työn nimi Arbetets titel Title Tietoturvan mallintaminen Oppiaine Läroämne Subject Työn laji Arbetets art Level Seminaari Tiivistelmä Referat Abstract Aika Datum Month and year 02.03.2005 Sivumäärä Sidoantal Number of pages 12 Tiedosta on tullut yrityksen toiminnan tärkein voimavara monilla aloilla, siksi yritysten toiminta edellyttää tiedon luotettavuuden, eheyden sekä saatavuuden varmistamista. Tietoturvan alalla on saavutettu monia merkittäviä läpimurtoja, kuten julkisen avaimen kryptografia. Teknologisesta edistyksestä huolimatta tietoturvan mallintaminen ja analysointi järjestelmän kehityksen aikaisessa vaiheessa on jäänyt vähälle huomiolle. Tietoturva on oleellinen osa järjestelmän kehityksen kaikissa vaiheissa, erityistä huomiota siihen tulisi kiinnittää jo järjestelmän suunnitteluvaiheessa. Tietoturvaan liittyviä uhkia mallinnetaan yleensä vasta toteutuksen yhteydessä tai huonoimmassa tapauksessa järjestelmän valmistuttua, yleinen ongelma on, ettei ole olemassa yhtenäistä merkintätapaa tietoturvavaatimusten määrittelyyn, keinoja vaatimusten analysointiin tai systemaattista lähestymistapaa tieturvaongelmien pohtimiseen järjestelmäsuunnittelun aikaisessa vaiheessa. Tietoturvan mallintamiseksi kehitetyistä ratkaisuista tarkastellaan hyväksikäyttötapausmalli, väärinkäyttötapausmalli, hyväksikäyttöviitemalli sekä järjestelmän toimijoiden välisen luottamuksen kuvaamiseen kehitetty Security-Aware Tropos. Avainsanat Nyckelord Keywords Tietoturva, mallintaminen, vaatimusanalyysi, väärinkäyttö Säilytyspaikka Förvaringställe Where deposited Muita tietoja Övriga uppgifter Additional information 1
Sisällysluettelo 1. Johdanto...3 2. Tietoturvan mallintaminen...4 3. Erilaisia ratkaisuja tietoturvan mallintamiseen...6 3.1. Abuse case...6 3.2. Misuse case...7 3.3. Käänteiset vaatimukset...8 3.4. Abuse frames...8 3.4.1. Esimerkki hyväksikäyttöviitemallin käyttämisestä...9 3.5. Security-Aware Tropos... 10 4. Yhteenveto... 12 5. Lähteet... 13 2
1. Johdanto Tiedosta on tullut yrityksen toiminnan tärkein voimavara monilla aloilla [LNI03], siksi yritysten toiminta edellyttää tiedon luotettavuuden (confidentiality), eheyden (integrity) sekä saatavuuden (availability) varmistamista. Tietoturvan parissa on tehty töitä usean vuosikymmenen ajan ja alalla on saavutettu monia merkittäviä läpimurtoja, kuten julkisen avaimen kryptografia [GMM04]. Teknologisesta edistyksestä huolimatta tietoturvan mallintaminen ja analysointi järjestelmän kehityksen aikaisessa vaiheessa on jäänyt vähälle huomiolle. Perinteinen vaalitusmäärittely laskee tietoturvan ei-toiminnallisiin vaatimuksiin, kuten myös luotettavuuden (reliability) ja tehokkuuden (performance), jotka määrittävät laadulliset rajoitukset, joiden mukaan järjestelmän tulee toimia. Tietoturvaan liittyviä uhkia mallinnetaan yleensä vasta toteutuksen yhteydessä tai huonoimmassa tapauksessa järjestelmän valmistuttua. Tietoturva on oleellinen osa järjestelmän kehityksen kaikissa vaiheissa, erityistä huomiota siihen tulisi kiinnittää jo järjestelmän suunnitteluvaiheessa. Kuitenkaan ei ole olemassa vakiintunutta käytäntöä tietoturvan suunnitteluvaiheen mallintamiseen tai analysointiin. Jopa Security Community on tunnustanut ongelmaksi sen, ettei ole olemassa yhtenäistä merkintätapaa tietoturvavaatimusten määrittelyyn, keinoja vaatimusten analysointiin tai systemaattista lähestymistapaa tieturvaongelmien pohtimiseen järjestelmäsuunnittelun aikaisessa vaiheessa. Luvussa kaksi käsitellään tietoturvan mallintamista yleisellä tasolla. Luvussa kolme käydään läpi joitakin tietoturvan mallintamiseksi kehitettyjä ratkaisuja, kuten hyväksikäyttötapaukset, väärinkäyttötapaukset sekä hyväksikäyttöviitemalli ja Security-Aware Tropos. 3
2. Tietoturvan mallintaminen BSI (British Standards Institution) määrittelee tietoturvan (information security) olevan tietovarallisuuden (information assets) suojaamista erilaisilta uhilta [CIL02]. Monien organisaatioiden toiminta on laajentunut kansainväliseksi ja siirtynyt yhä suuremmassa määrin verkkoon. Nykypäivän tietoyhteiskunnassa tiedosta on tullut yrityksen toiminnan tärkein voimavara monilla aloilla [LNI03], siksi yritysten toiminta edellyttää tiedon luotettavuuden, eheyden ja saatavuuden varmistamista erilaisin tietoturvan keinoin. Tietojärjestelmien tietoturvan parissa on tehty töitä jo yli kolmenkymmenen vuoden ajan [Lam00]. Tänä aikana on saavutettu monta edistysaskelta, kuten julkisen avaimen kryptografia (public key cryptography), pääsymatriisit (access matrix model), pääsynvalvontalistat (access control lists) sekä erilaiset kryptografian algoritmit. Huolimatta monista teknologisista edistysaskelista, jopa suurista organisaatioista löytyy kohteita, joiden tietoturva on heikolla tasolla. Suurimmassa osassa Internetiin kytketyistä koneista asiansa osaava hakkeri saattaisi milloin tahansa kyetä tuhoamaan, varastamaan tai muuttamaan koneelle tallennettua tietoa [Lam00]. Mikä pahinta, nykyisellä laskentateholla hyökkääjä saattaisi tehdä tämän jopa miljoonille koneille kerralla. Vaikka kehityksen suuntana on jo pitkään ollut yhteiskunta, jossa tiedon merkitys korostuu, ei siltikään ole olemassa kattavia tutkimuksia siitä, mikä tietoturvan pettämisen todellinen kustannus on [Lam00]. Vaikka tietoturva koetaan tärkeäksi, ei siihen haluta panostaa suuria summia tai työtunteja eikä sen takia haluta tehdä myönnytyksiä käytettävyyden suhteen. Tietoturvan kehittyessä on kehitetty lukuisia erilaisia tekniikoita tietokoneelle tallennetun tiedon hallintaan (managing) ja turvaamiseen (protecting) [LNI03]. Nämä tekniikat keskittyvät kuitenkin erilaisiin tekniikoihin tai toteutusmalleihin, jotka parantavat tietoturvaa. Kuitenkin tietoturvauhkia tulisi mallintaa jo järjestelmän suunnitteluvaiheessa. Vaikka Security Community on tunnustanut tietoturvan mallintamisen tärkeäksi, se myöntää, ettei edelleenkään ole olemassa sopivaa notaatiota tietoturvavaatimusten määrittelyyn, keinoja vaatimusten analysointiin tai systemaattista lähestymistapaa tieturvaongelmien pohtimiseen järjestelmäsuunnittelun aikaisessa vaiheessa [LNI03]. 4
Näihin ongelmiin ja niiden mallintamiseen on yritetty kehittää monenlaisia ratkaisuja, kuten UML-kieleen (Unified Modelling Language) perustuvat SecureUML sekä UMLsec [GMM04], McDermottin ja Foxin malli hyväksikäyttötapauksille (abuse case model) [GMM04], Sindren ja Opdahlin väärinkäyttötapaukset (misuse case model) [GMM04]. Erilaisen näkökulman järjestelmän vaatimusmäärittelyyn tuo Crook, joka mallintaa pahantahtoisen käyttäjän vaatimukset, käänteiset vaatimukset (anti-requirements) jo järjestelmän vaatimusmäärittelyn yhteydessä [CIL02]. Lin n & Al:n järjestelmän hyväksikäytönviitemalli (abuse frames) mallintaa tietoturvauhkia määrittelemällä hyökkäyksen kohteen, hyökkäyksen mahdollistavan haavoittuvuuden sekä hyökkääjän käänteiset vaatimukset [LNI03, LNI04]. Edellä mainitut ratkaisut mallintavat tietojärjestelmää, poliitikoita ja järjestelmän tarjoamaa pääsynvalvontamekanismia, eli ovat järjestelmälähtöisiä (system-oriented) [GMM04]. On kuitenkin nähty tarvetta mallille, joka tukisi luottamuksen ja luottamussuhteiden mallintamista ja analysoimista organisatorisella tasolla. Security-Aware Tropos pyrkii vastaamaan näihin ongelmiin määrittelemällä luottamusmallin järjestelmässä toimivien toimijoiden välille sekä tuottamalla toiminnallisen kuvauksen toimijoiden välisistä suhteista [GMM04]. 5
3. Erilaisia ratkaisuja tietoturvan mallintamiseen Tietoturvan mallintamiseen on kehitetty monia ratkaisuja, tässä luvussa käsitellään eräitä niistä. 3.1. Abuse case McDermott ja Fox käyttävät käyttötapausmäärittelyitä (use case) mallintaakseen järjestelmän väärinkäyttöä [GMM04, McF99]. Hyväksikäyttötapaus (abuse case) pyrkii kuvaamaan täydellisesti järjestelmän ja yhden tai useamman siihen liittyvän toimijan välisen toiminnan, jossa toiminnan tulos on haitallinen itse järjestelmälle, siihen liittyville toimijoille, tai systeemin omistajille [GMM04]. Kuva 3.1. Käyttötapauksen mallintaminen [McF99] Malli käyttää samaa notaatiota hyväksikäyttötapausten mallintamiseen kuin käyttötapausmäärittely [McF99]. Kuvassa 3.1. on esitetty käyttötapausten määrittelyyn käytettävä notaatio. Jokaisessa käyttötapauksessa on toimija, johon liittyy yksi tai useampi käyttötapaus. Kuva 3.2. Hyväksikäyttötapauskaavio, tietoliikennelaboratorio[mcf99] Kuvassa 3.2. on esitetty yksinkertainen esimerkki hyväksikäyttötapauksen mallintavasta UMLkaaviosta. Kuvassa esitetään pahantahtoisen oppilaan mahdolliset käyttötapaukset tietoliikennelaboratoriossa suoritettavaan kotitehtävään liittyen [McF99]. Pahantahtoinen oppilas saattaa kopioida toisen oppilaan tehtävän, muuttaa tehtävästä saatavia pisteitä tai muuttaa itse tehtävää. 6
3.2. Misuse case Sindren ja Opdahlin malli laajentaa käyttötapausmallia määrittelemällä väärinkäytön (misuse) käsitteen. Väärinkäyttötapauksella (misuse case) tarkoitetaan käyttötapauksen käänteistä tapausta, joka kuvaa toiminnon, jota järjestelmän ei tulisi sallia [GMM04, SiO01]. Käyttötapaukset ottavat kantaa siihen, miten järjestelmän tulisi toimia, kun taas väärinkäyttötapaukset kuvaavat päinvastaista [SiO01]. Väärinkäyttötapausten malli eroaa McDermottin ja Foxin hyväksikäytön mallista siinä, että pahantahtoisen käyttäjän toiminnan lisäksi siinä mallinnetaan myös järjestelmän normaali toiminta. Kuva 3.3. Osittainen e-kaupan sovelluksen väärinkäyttökaavio[sio01] Kuvassa 3.3. on esitetty osittainen diagrammi kaupallisen järjestelmän väärinkäyttötapauksesta. Kuvassa on tavalliset käyttötapaukset esitetty valkoisin alkioin ja hyväksikäyttötapaukset mustalla [SiO01]. Samoin järjestelmässä toimiva käyttäjä (actor) ja väärinkäyttäjä (mis-actor) ovat esitetty toisistaan eroavilla merkintätavoilla. Väärinkäyttötapausten ja tavallisten käyttötapauksien välillä saattaa olla riippuvuussuhteita, esimerkiksi tietty väärinkäyttötapaus saattaa vaatia jonkin laillisen käyttötapauksen suorittamista. Esimerkiksi kuvan tapauksessa palvelunestohyökkäys (Denial of Service, DoS) voidaan toteuttaa tulvittamalla järjestelmää asiakkaan rekisteröintipyynnöillä. Tämän tyyppinen hyökkäys voidaan välttää estämällä toistuvat järjestelmään tulevat rekisteröintipyynnöt. 7
3.3. Käänteiset vaatimukset Järjestelmän käänteisillä vaatimuksilla (anti-requirements) tarkoitetaan järjestelmää kohtaan hyökkäävän pahantahtoisen käyttäjän vaatimuksia [CIL02]. Oleellista näissä vaatimuksissa on, että vaatimukset ovat nimenomaan järjestelmään kohti hyökkäävän käyttäjän generoimia vaatimuksia. Yleensä vaatimusanalyysi tuottaa ristiriitaisia tai epäjohdonmukaisia vaatimuksia, jotka eivät käsittele tietoturvakysymyksiä, joita generoidaan joko uhkakuva-analyysin tai hyökkäyksen jälkeisen reagoinnin tuloksena. 3.4. Abuse frames Tähän ongelmaan pureutuakseen Lin & al. ovat esittäneet hyväksikäytön viitemallin (abuse frames) järjestelmän tietoturvauhkien mallintamiseen ja analysointiin [LNI03, LNI04]. Malli perustuu Jacksonin järjestelmän käyttöongelmien mallintamiseen (problem frames) ja se käyttää hyväkseen Crookin käänteisiä vaatimuksia [LNI03]. Viitemalli antaa työkalut tietoturvauhkien mallintamiseen. Lähestymistapa käyttää samaa merkintätapaa kuin Jacksonin ongelmamalli, mutta hyväksikäytön viitemallissa tilannetta tarkastellaan pahantahtoisen käyttäjän näkökulmasta ja jokaiseen osa-alueeseen liittyvät eri tarkoitukset [LNI03]: Machine Domain pitää sisällään ne haavoittuvuudet, joita pahantahtoinen hyökkääjä käyttää hyväkseen hyökkäyksessään. Victim Domain pitää sisällään hyökkäyksen kohteena olevat alkiot, esimerkiksi tietovarallisuuden. Malicious User Domain yhdistettynä käänteiseen vaatimukseen kuvaavat uhan muodostavan toimijan (hyökkääjän). Kuva 3.4. Tietoturvauhan kuvaamisen viitemalli[lni03] 8
3.4.1. Esimerkki hyväksikäyttöviitemallin käyttämisestä Seuraavassa esimerkissä käytetään järjestelmän hyväksikäytön viitemallia liikennevalojen tietoturvauhkien mallintamiseen suunniteltaessa liikennevaloja. Ongelma voidaan jakaa kahteen osa-ongelmaan: liikennevalojen ohjausyksikkö (lights controller) sekä liikennevalojen hallintajärjestelmään (light regitime editor) [LNI04]. Molempiin liittyvät omat tietoturvaongelman ja molemmat osat voidaan kuvata erillisillä hyväksikäyttökaavioilla. Liikennevalojen ohjausyksikkö on kytketty suoraan liikennevaloihin [LNI04]. Sen tehtävänä on saada liikennevalojen valot näyttämään liikennevalojen hallintajärjestelmän määrittämiä signaaleja. Tämän osaongelman eräs mahdollinen käänteinen vaatimus olisi saada liikennevalojen ohjausyksikkö ohjaamaan valoilla virheellinen valosarja (Kuva 3.5). Kuva 3.5. Liikennevalojen ohjausyksikköön liittyvien tietoturvaongelmien mallintaminen [LNI04] Kuvassa liikennevalojen ohjausyksikkö lähettää signaalin valoille (a). Virheellinen signaali saa valot käyttäytymään määrittelyidensä vastaisesti (b), esimerkiksi näyttämään punaista ja vihreää valoa yhtä aikaa. Kuva 3.6. Liikennevalojen hallintajärjestelmään liittyvien tietoturvaongelmien mallintaminen[lni04] Liikennevaloihin liittyvien ongelmien tarkastelua voidaan jatkaa liikennevalojen hallintajärjestelmässä. Hallintajärjestelmä sallii valojen operaattorin (operator) muuttaa järjestelmään määriteltyä valojen toimintaa [LNI04]. Kuvassa 3.6. on esitetty tämän osaongelman 9
potentiaaliset tietoturvauhat. Pahantahtoisen käyttäjän muuttaessa operaattorin syöttämiä käskyjä (c), käskyjen editointiohjelma syöttää ne liikennevalojen hallintajärjestelmään (d) aiheuttaen luvattoman muokkaamisen liikennevalojen toiminnassa (e). Kuvassa 3.7. on nähtävissä näiden vaikutus liikennevalojen toiminnassa. Kuvassa on nähtävissä, miten pahantahtoisen käyttäjän luvattomat muutokset liikennevalojen hallintajärjestelmässä aiheuttavat liikennevalojen valoyksikön määrittelyiden vastaisen valosarjan. Kuva 3.7. Liikennevalojen tietoturvaongelmien mallintaminen [LNI04] 3.5. Security-Aware Tropos Tropoksen tavoitteena on mallintaa sekä järjestelmän organisatorista ympäristöä että itse järjestelmää [GMM04]. Se käyttää toimijan (actor), päämäärän (goal), resurssin (resource) sekä sosiaalisten riippuvuuksien (social dependency) käsitteitä määritelläkseen riippuvuussuhteessa olevien toimijoiden (dependees) velvollisuuksia toisiin toimijoihin (dependers). Giorgini & Al. ovat kehittäneet Troposia edelleen tähdäten prosessiin, joka yhdistää luottamuksen (trust), tietoturvan sekä järjestelmäsuunnittelun (system engineering) [GMM04]. Mallin tarkoituksena on: 1. määritellä luottamusmalli järjestelmässä toimivien toimijoiden välille 2. määritellä kuka omistaa päämäärät, tehtävät tai resurssit ja kuka on kykenevä saavuttamaan päämäärät, suorittamaan tehtävät tai toimittamaan resurssit 3. määritellä toiminnalliset riippuvuudet sekä päämäärien jaot agenttien välillä, jonka tuloksena järjestelmän toiminnallinen kuvaus 10
Tropoksen mallin perusidea on, että jokaisella resurssilla on omistaja, jolla on täydet oikeudet resurssiin (O). Omistajalla on myös oikeus siirtää samat oikeudet toiselle järjestelmässä toimivalle toimijalle (P). Mallissa merkitään myös luottamussuhteet (T) sekä toimijoiden ja resurssien väliset Tropos-riippuvuudet (D). Kuva 3.8. Tropoksen mukainen sairaalan luottamusmalli (a) sekä toiminnallinen malli (b) [GMM04] Kuvassa 3.8. on esitettynä yksinkertaistettu Tropos-kaavio sairaalan ja potilaan välisestä luottamusmallista (a) sekä toiminnallisesta mallista (b). Luottamusmallissa sairaala omistaa (O) oikeudet tarjoamaansa hoitoon ja potilas omistaa (O) oikeudet omiin tietoihinsa. Potilas luottaa (T) sairaalaan omien potilastietojensa käytössä. Toiminnallisesta mallista selviät sairaalan ja potilastietojen sekä potilaan väliset riippuvuussuhteet (D), samoin riippuvuudet potilaan, sairaalan tarjoaman sairaalahoidon sekä sairaalan välillä. Potilas antaa sairaalalle oikeudet omiin tietoihinsa (P). Kuva 3.9. Laajennettu luottamusmalli sairaalan ja potilaan välillä [GMM04] Tropoksen avulla voidaan rakentaa hyvinkin monimutkaisia malleja koskien toimijoiden välistä luottamusta, riippuvuuksia ja omistussuhteita [GMM04]. Kuvassa 3.9. on esitetty laajennettu versio kuvan 3.8. (a) luottamusmallista. Malliin voidaan sisällyttää useampia toimijoita, resursseja ja päämääriä, jolloin ongelmaa voidaan tarkastella entistä tarkemmalla tasolla. 11
4. Yhteenveto Organisaatioiden toiminnan siirtyessä yhä suuremmassa määrin verkkoon tiedosta on muodostunut yksi yrityksen toiminnan tärkeimmistä voimavaroista. Tietoturvan parissa on tehty töitä vuosikymmenien ajan ja edelleen sen merkitys vain kasvaa yritysten pyrkiessä varmistamaan tiedon luotettavuuden, eheyden ja saatavuuden erilaisin tietoturvan keinoin. Tietoturvan kehityksen aikana on kehitetty lukuisia erilaisia tekniikoita tietokoneelle tallennetun tiedon hallintaan ja turvaamiseen. Nämä tekniikat keskittyvät kuitenkin lähinnä suunnitteluprosessiin ja toteutuksen ongelmiin, kuten turvalliseen suunnitteluprosessiin ja hyökkäysten havaitsemiseen. Näihin ongelmiin ja niiden mallintamiseen on yritetty kehittää monenlaisia ratkaisuja, kuten UML-kieleen (Unified Modelling Language) perustuvat SecureUML sekä UMLsec, McDermottin ja Foxin malli hyväksikäyttötapauksille, Sindren ja Opdahlin väärinkäyttötapaukset. Lin n ja Jacksonin hyväksikäyttöviitemalli mallintaa tietoturvauhkia määrittelemällä hyökkäyksen kohteen, hyökkäyksen mahdollistavan haavoittuvuuden sekä Crookin mallin noudattavat käänteiset vaatimukset. Edellä mainitut ratkaisut ovat kuitenkin järjestelmälähtöisiä, eli ne mallintavat tietojärjestelmää, poliitikoita ja järjestelmän tarjoamaa pääsynvalvontamekanismia. On kuitenkin nähty tarvetta mallille, joka tukisi luottamuksen ja luottamussuhteiden mallintamista ja analysoimista organisatorisella tasolla. Ratkaisuksi organisatorisen tason tietoturvan mallintamiseen on kehitetty Security-Aware Tropos. 12
5. Lähteet [CIL02] Crook, R., Ince, D., Lin, L., Nuseibeh, B. Security Requirements Engineering: When Anti-requirements Hit the Fan, Proceedings of the 10 th IEEE International Requirements Engineering Conference (RE 02), 2002 [GMM04] Giorgini, P., Massacci, F., Mylopoulos, J., Zannone, N. Requirements Engineering Meets Trust Management - Model,Methodology and Reasoning, Proceedings of the 2 nd International Conference on Trust Management, 2004 [Lam00] Lampson, B. W. Computer Security in Real World, Proceedings of the 16 th Annual Computer Security Applications Conference (ACSAC 00), 2000 [LNI03] Lin, L., Nuseibeh, B., Ince, D., Jackson, M. Introducing Abuse Frames for Analysing Security Requirements, Proceedings of the 11 th IEEE International Requirements Engineering Conference (RE 03), 2003 [LNI04] Lin, L., Nuseibeh, B., Ince, D., Jackson, M. Using Abuse Frames to Bound the Scope of Security Problems, Proceedings of the 12 th IEEE International Requirements Engineering Conference (RE 04), 2004 [McF99] McDermott, J., Fox, C. Using Abuse Case Models for Security Requirements Analysis, Proceedings of the 15 th Annual Computer Security Applications Conferense (ACSAC 99), 1999 [SiO01] Sindre, G., Opdahl, A. Templates for Misuse Case Description, Proceedings of the 7 th International Workshop on Requirements Engineering, Foundation for Software Quality (REFSQ 2001), 2001 13